Greg Hudson wrote:
>>> Sure, but what needs to do this?
>>
>> I'd think getting to the tip of any branch is the first thing you
>> need to do for updates and checkouts.
>
> Nah, the global commit number points to a root directory
> node-revision, and its diretory entries point to other node-revisions,
> and so forth.
Hm. O.K.
> I did think of something which needs to walk around the version tree,
> though: "svn log". Thinking about "svn log" led me to some other
> questions about the current model, though:
>
> * Is there any internal difference between "svn branch" and
> "svn cp"?
That depends on what you wand "svn cp" to do. To me it seems that it
should copy the node, history and all. That's certainly different from
branching, and also different from "cp && svn add".
Oh, but then you'd lose information about the ancestor node.
> * Suppose I "svn cp" foo.c to bar.c, and then modify both
> files. If foo.c was at node-revision 1.2 before the copy,
> which file's changes become 1.3 and which changes become
> 1.2.1.1, and how does the database keep track of that?
> (Does bar.c immediately point to a 1.2.1.1 revision even
> though there are no differences in contents or properties
> between 1.2.1.1 and 1.2?) Will "svn log foo.c" show
> information about the changes made to bar.c?
>
> The current numbering system gives distinguished status to one of the
> descendents of node-revision, which seems artificial to me. And
> separately, I'm concerned about our current ability to determine which
> node-revisions a version tree should be reported by "svn log".
I think what you're describing here is a mechanism that's actually
orthogonal to branching. Semantically, a copy creates a new node, not a
new revision (unlike rename). But you want to maintain history. This
implies having some sort of inter-node links with which you can connect
two version graphs. Not unheard of, certainly.
>> You'd need to store informatin about successors and predecessors in
>> the node data. That means changing two records, not one, for every
>> new vesion added.
>
>
> I was thinking just ancestor pointers, but "svn log" will also need
> descendent pointers. So you're right. But two records will have to
> be changed when a node-revision is added anyway: the new node-revision
> needs to be created with contents ("full-text" new-contents), and the
> old node-revision needs to be changed to have contents ("younger"
> diff-data checksum). If only the latter change happens, the database
> is inconsistent. So there's no new consistency issue associated with
> keeping the data in pointers.
As Jim said, that's an optimisation. I don't think this argument applies.
--
Brane �ibej
home: <brane_at_xbc.nu> http://www.xbc.nu/brane/
work: <branko.cibej_at_hermes.si> http://www.hermes-softlab.com/
ACM: <brane_at_acm.org> http://www.acm.org/
Received on Sat Oct 21 14:36:16 2006