[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: filesystem oops?

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-02-04 21:21:24 CET

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.

> 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.

As for the immediate problem:

I'd say, factor the predecessor calculation, put in whatever special
cases are needed for now, change the code so that future repositories
get .0 for new node, and file an issue (linked with the repository
cleanup issue) about taking the special cases out.

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? Then there's no need for a special
case, just decrement all the way to .0, inclusive, testing each one.
If you don't find one at .0, that's fine -- no different than not
finding a node at .1 or .2 or whatever.

-K

---------------------------------------------------------------------
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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.