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

RE: RE: Keeping NodeRevisionIDs from being unbounded

From: Bill Tutt <rassilon_at_lyra.org>
Date: 2002-03-08 21:01:14 CET

> From: Bill Tutt [mailto:rassilon@lyra.org]
> > From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> >
> >
> > One cost that does change is finding the immediate predecessor of a
> > given node revision. Currently, it is usually constant time and
> > requires no DB access -- you can do it *entirely* by looking at the
> > NodeID, and when you can't, you can tell that by inspection
instantly.
> >

Aside from my raving about how to continue storing ancestry information
inline. I think I misunderstood what you were saying here.

I think you were saying that the immediate predecessor was immediately
available from the PK. Which is no longer true. Where is this actually
important?

The only place we currently call svn_predecessor_id() from atm is during
stabilization which we said we no longer needed. If there are other
parts of the code that do this manually, we definitely need to do some
more thinking here.

If this is actually important, you can still preserve the Changeset
function by altering the PK thusly: (NodeID, ChangeSetID, ChangeID)
where ChangeID increases monotonically based on the NodeID, is set
during the (or at the same point in the code as) stabilization phase,
and is null for any pending ChangeSet.

Bill

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 8 21:01:57 2002

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.