"Bill Tutt" <rassilon@lyra.org> writes:
> 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?
It's not, really -- and we can get it in a one-shot DB lookup, so no
big deal.
> 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.
I think it won't be necessary to do that. If we have to ask for
predecessors at all, the number of askings is going to be proportional
to the size of the change, and having to do a number of DB access
proportional to the size of the change is no big deal -- I mean, this
is a *commit*, after all, we just sent the data over the network. :-)
-K
---------------------------------------------------------------------
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:37:34 2002