While debugging some new filesystem functionality, I noticed an
interesting...um...feature of the way node IDs are handed out.
For some reason, only the root node ever gets a node revision whose
final component is '0'. '0.0' is always the first node created in the
filesystem. All nodes created after that are either a successor the
root node (e.g. '0.1', '0.2', '0.0.1.1' ... ) or begin a new node
ancestry, but with a final component of '1' (e.g. '1.1', '2.1', ... ).
Now of course, node IDs are just node IDs ... no big deal. The only
problem I see with it so far is that question "What is the predecessor
ID of 0.1?" is answered incorrectly. The ID crunching code assumes
that the final component of a valid node ID is always > 0. As a
result, the calculation of the predecessor is usually this simple:
1. decrement the final component of ID.
2. if the final component of ID is still > 0, return ID as a predecessor,
else, hack off the last two components of ID.
3. if this now-two-components-shorter ID still has components, return
it as a predecessor, else return the fact that this ID has no precessor.
This works great for nearly all nodes in the filesystem. Here's an
example of the list of predecessors to "10.3.19.2":
"10.3.19.1"
"10.3.19.0" is invalid, so "10.3"
"10.2"
"10.1"
"10.0" is invalid, so "", which has no components. End of the lineage.
We find that 10.3.19.1, 10.3, 10.2, and 10.1 are predecessors of 10.3.19.2.
This falls apart on the root node, because it, too, will stop at "0.1"
... one predecessor short of the truth.
So, we have two choices to make as I see it:
1. Change the code so that the first node created is always 0.1 (not
0.0), or
2. Live with this annoying "special case" exception when doing
predecessor calculation (which is done in more than one place in
the filesystem).
I feel that 1 is the Right Thing, but I'm not volunteering to renumber
the thousands of root-path IDs currently living in our own repository.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:04 2006