>> 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.
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"?
* 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".
> 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.
> Right now, the consistency of the version tree depends on the
> correctness of one function -- the key comparator for the "nodes"
> table.
But the consistency of the representations is dependent on more than
that.
Received on Sat Oct 21 14:36:16 2006