cmpilato@collab.net wrote:
>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.
>
You know, I can't for the life of me remember why the last component of
a node id can't be 0. Unless somevody comes up with a good reason for
that, I'd suggest we just allow node id's to start with 0 (X.0, X.0.Y.0
X.Y.Z.0, ...) and fix the predecessor calculation appropriately.
--
Brane Čibej <brane_at_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
Received on Sat Oct 21 14:37:04 2006