You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Harald Wellmann <Ha...@gmx.de> on 2003/03/11 23:06:23 UTC
Getting complete revision history with the current DB model
Sorry if this is a FAQ; I found quite a few messages in the archives
regarding version trees etc. but they didn't really answer my question...
Looking at a given node in a working copy, "svn log" lists all revisions
from the current one back to the root of version tree of your node. But
this is just one path in the version tree, and sometimes you want to see
the complete tree, e.g. to find out if someone has branched off from an
earlier version of your node and made some changes that you may have to
merge.
I remember reading a posting saying that all required information is
contained in the BDB "copies" table. Well, if I'm not mistaken, all the
information *is* contained in the DB, but you'd have to scan all entries
of some tables for lack of suitable indices or foreign keys.
You get the predecessor of each node revision and the children of each
directory node at constant cost, but to dump the complete history of a
node, you have to find the successor revisions and then the parent
directory to map your node to a path name.
Am I missing something obvious? If not, are there any plans to extend
the DB model? Or should we wait for an SQL DB backend and then get all
sorts of queries nearly for free?
Regards,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Getting complete revision history with the current DB model
Posted by Branko Čibej <br...@xbc.nu>.
Harald Wellmann wrote:
> Branko Čibej schrieb:
>
>> Ben Collins-Sussman wrote:
>>
>>> Alas, you are correct. Subversion cannot (yet) track a node's history
>>> in a forward direction, other than by brute force searching. The copy
>>> data allows you to track backwards, a la 'svn log'. So for now, you
>>> won't find any pretty Clearcase-like node diagrams coming out of
>>> Subversion.
>>>
>>
>> What we can do, though -- once the rename behaviour is fixed -- is
>> search for all isntances of a node id, then search backwards from each
>> and construct a tree that way. That's almost as good.
>>
>>
>
> Oops, I didn't realize rename was broken... What's wrong with it, and
> how is it going to be fixed?
Rename is implemented as "copy+delete", which means that the renamed
file gets a different node ID than the original. We have code on a
branch that preserves the node ID during renames (but only on the
filesystem side, the WC side hasn't been touched yet).
Once that code--including WC bits--gets in, a node will keep the same ID
throughout its history, which should make these queries easier.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Getting complete revision history with the current DB model
Posted by Ben Collins-Sussman <su...@collab.net>.
Harald Wellmann <Ha...@gmx.de> writes:
> > What we can do, though -- once the rename behaviour is fixed -- is
> > search for all isntances of a node id, then search backwards from each
> > and construct a tree that way. That's almost as good.
> >
>
> Oops, I didn't realize rename was broken... What's wrong with it, and
> how is it going to be fixed?
It's broken in that there *is* no svn_fs_rename().
We currently implement renames by doing an "add with history" and a
"delete". Others (cmpilato, brane) can talk about future plans.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Getting complete revision history with the current DB model
Posted by Harald Wellmann <Ha...@gmx.de>.
Branko Čibej schrieb:
> Ben Collins-Sussman wrote:
>
>>Alas, you are correct. Subversion cannot (yet) track a node's history
>>in a forward direction, other than by brute force searching. The copy
>>data allows you to track backwards, a la 'svn log'. So for now, you
>>won't find any pretty Clearcase-like node diagrams coming out of
>>Subversion.
>>
>
> What we can do, though -- once the rename behaviour is fixed -- is
> search for all isntances of a node id, then search backwards from each
> and construct a tree that way. That's almost as good.
>
>
Oops, I didn't realize rename was broken... What's wrong with it, and
how is it going to be fixed?
Regards,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Getting complete revision history with the current DB model
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>Harald Wellmann <Ha...@gmx.de> writes:
>
>
>
>>You get the predecessor of each node revision and the children of each
>>directory node at constant cost, but to dump the complete history of a
>>node, you have to find the successor revisions and then the parent
>>directory to map your node to a path name.
>>
>>
>
>Alas, you are correct. Subversion cannot (yet) track a node's history
>in a forward direction, other than by brute force searching. The copy
>data allows you to track backwards, a la 'svn log'. So for now, you
>won't find any pretty Clearcase-like node diagrams coming out of
>Subversion.
>
What we can do, though -- once the rename behaviour is fixed -- is
search for all isntances of a node id, then search backwards from each
and construct a tree that way. That's almost as good.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Getting complete revision history with the current DB model
Posted by Ben Collins-Sussman <su...@collab.net>.
Harald Wellmann <Ha...@gmx.de> writes:
> There was a remark in the 0.19 release notes about "adding support for
> multiple fs backends" - what would that be? I didn't notice any
> significant changes in the libsvn_fs sources - I was expecting some
> sort of abstraction for all the svn_fs__bdb* function calls.
This is work is slowly happening on a branch:
$ svn ls -v http://svn.collab.net/repos/svn/branches
_ 3932 fitz 0 Nov 29 08:43 broken-book/
_ 4201 jerenkra 0 Dec 28 19:02 dav-mirror/
_ 2773 sussman 0 Jul 29 14:30 fs-convert-2490/
_ 5146 cmpilato 0 Feb 27 21:28 fs-schema-changes/
_ 5000 cmpilato 0 Feb 20 17:20 issue-1003-dev/
_ 5286 mass 0 Mar 11 22:20 issue-650-ssl-certs/
_ 2212 kfogel 0 Jun 14 10:35 issue-662-dev/
_ 4962 jerenkra 0 Feb 19 12:15 issue-951-dev/
_ 5273 gthompso 0 Mar 11 01:14 pluggable-db/
I believe it's gat's "pluggable-db" branch. Read the log messages for
that branch.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Getting complete revision history with the current DB model
Posted by cm...@collab.net.
Michael Price <mp...@atl.lmco.com> writes:
> No. The release note is spot on. The misquote of it is just plain wrong.
>
> The actual note says:
>
> "start adding support for multiple fs backends"
>
> The word "start" being the key word here.
Ah, yes. You are right. I am wrong. And Harald is just confused. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Getting complete revision history with the current DB model
Posted by Michael Price <mp...@atl.lmco.com>.
cmpilato@collab.net writes:
> Harald Wellmann <Ha...@gmx.de> writes:
>
> > There was a remark in the 0.19 release notes about "adding support for
> > multiple fs backends" - what would that be? I didn't notice any
> > significant changes in the libsvn_fs sources - I was expecting some
> > sort of abstraction for all the svn_fs__bdb* function calls.
>
> Oops, that release note was just plain wrong. Some work was done
> toward paving the way for pluggable backends, but the actual FS
> abstraction work is being done on a branch, not in the main
> development line.
No. The release note is spot on. The misquote of it is just plain wrong.
The actual note says:
"start adding support for multiple fs backends"
The word "start" being the key word here.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Getting complete revision history with the current DB model
Posted by cm...@collab.net.
Harald Wellmann <Ha...@gmx.de> writes:
> There was a remark in the 0.19 release notes about "adding support for
> multiple fs backends" - what would that be? I didn't notice any
> significant changes in the libsvn_fs sources - I was expecting some
> sort of abstraction for all the svn_fs__bdb* function calls.
Oops, that release note was just plain wrong. Some work was done
toward paving the way for pluggable backends, but the actual FS
abstraction work is being done on a branch, not in the main
development line.
> What's the current status of SQL support? Vague ideas, solid
> requirements, active development on a dedicated branch...?
Glenn Thompson has a very well-defined plan, the design docs for which
he is polishing up right now for public consumption. He's done alot
of the work, too, but those changes aren't yet committed to the
branch.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Getting complete revision history with the current DB model
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
>
>
> Hmmh, can you be a bit more specific?
>
Harald, I'm working on a response.
posting shortly.
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Getting complete revision history with the current DB model
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
>
> What's the current status of SQL support? Vague ideas, solid
> requirements, active development on a dedicated branch...?
The short answer is re-documention.
A GAT answer :-)
gstein(and others I'm sure) had major reservations about my plans. I
use the word plans instead of design as my previous documentation was
hardly a design:-) The design is in the ol brain. It just needs to come
out in a more organized and sequential way. My mind works somewhat like
a vortex. When my thoughts are left to their own devices, they leave my
brain on a tangent. :-) I'm roping them in now.
Last year, while cmpilato made major FS changes, I went off in my own
little world and produced this:
http://www.cdrguys.com/subversion/sql_fs_docs/svn_fs_sql.html
Which is predicated on this:
http://www.cdrguys.com/subversion/fs_refactoring/index.html
which is a continuation of the work cmpilato did.
Which resulted in the patches:
http://www.cdrguys.com/subversion/index.html and some code no one has
seen yet.
Which resulted in: "Hey you need work on a branch so people can follow
along better".
The pluggable-db branch was born.
I will be posting the original docs in the notes directory of that
branch. They will be replaced with newer documentation piece by piece.
Then I will resume patching.
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Getting complete revision history with the current DB model
Posted by Harald Wellmann <Ha...@gmx.de>.
Ben Collins-Sussman schrieb:
> Harald Wellmann <Ha...@gmx.de> writes:
>
>
>>If not, are there any plans to extend the DB model?
>
>
> Yes.
>
>
>>Or should we wait for an SQL DB backend and then get all sorts of
>>queries nearly for free?
>
>
> Yes. :-)
Hmmh, can you be a bit more specific?
There was a remark in the 0.19 release notes about "adding support for
multiple fs backends" - what would that be? I didn't notice any
significant changes in the libsvn_fs sources - I was expecting some sort
of abstraction for all the svn_fs__bdb* function calls.
What's the current status of SQL support? Vague ideas, solid
requirements, active development on a dedicated branch...?
Regards,
Harald
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Getting complete revision history with the current DB model
Posted by Ben Collins-Sussman <su...@collab.net>.
Harald Wellmann <Ha...@gmx.de> writes:
> You get the predecessor of each node revision and the children of each
> directory node at constant cost, but to dump the complete history of a
> node, you have to find the successor revisions and then the parent
> directory to map your node to a path name.
Alas, you are correct. Subversion cannot (yet) track a node's history
in a forward direction, other than by brute force searching. The copy
data allows you to track backwards, a la 'svn log'. So for now, you
won't find any pretty Clearcase-like node diagrams coming out of
Subversion.
> Am I missing something obvious?
No.
> If not, are there any plans to extend the DB model?
Yes.
> Or should we wait for an SQL DB backend and then get all sorts of
> queries nearly for free?
Yes. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org