Karl Fogel <kfogel@newton.ch.collab.net> writes:
> cmpilato@collab.net writes:
> > 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).
>
> Perhaps first factor the predecessor calculation so that it's done in
> exactly one place in the filesystem -- then having a special case in
> it won't be so painful.
Sorry, I should have explained that a little better. There is an
svn_fs_predecessor_id() function, for operations that need to fly
backward in node-Id ancestry, it's ridiculous to be allocating each
predecessor from the pool when the simple calculation can be done
in-place (using once-alloced memory).
> > 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.
>
> Or, there's Right Thing here:
>
> Make new nodes get ".0" instead of ".1", to match the original root
> node. IMHO, this is how it should have been in the first place.
So...rather than have our current repository have one wrong node, we
should have hundreds? The 0 vs. 1 is a total bikeshed -- don't waste
my time on it. The point is that all the current code (from
predecessor calculation to id distance calculation to successor
generation and beyond) expects .1. Why rewrite the whole friggin'
system for such a ridiculous bikeshed?
> Question: don't we have to check that a given predecessor ID actually
> exists anyway (i.e., there is a node for it in the fs?), once we think
> we've calculated that predecessor?
No. We would have never gotten the current ID if its predecessor
hadn't existed.
---------------------------------------------------------------------
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