Karl Fogel <kfogel@galois.ch.collab.net> writes:
> Jim Blandy <jimb@zwingli.cygnus.com> writes:
> > > > Since revision numbers increase by one each time a delta is added,
> > > > we can compute how many deltas separate two related node revisions
> > > > simply by comparing their ID's. For example, the distance between
> > > > 100.10.3.2 and 100.12 is the distance from 100.10.3.2 to their
> > > > common ancestor, 100.10 (two deltas), plus the distance from 100.10
> > > > to 100.12 (two deltas).
> > >
> > > This metric really isn't true anymore is it? I mean we can't really
> > > say (in the example above) that the two node revisions are 4 deltas
> > > apart, because we can have "holes" in our nodes table, right?
> >
> > Can you give me an example of the sort of hole you have in mind?
>
> I think he meant:
>
> Jane starts a Subversion txn.
> Bill starts a Subversion txn.
> Jane makes a change to node N in her txn.
> Bill makes a change against the same base revision of N, in his txn.
> Jane aborts her txn.
> Bill commits his txn.
Yup. Aborted transactions result in deleted node-revisions.
My thoughts weren't as complex as Karl's, though; if Jane begins and
then aborts a transaction -- acting alone -- the deleted node-revision
numbers will never be recycled, right? The next person who comes
along and clones the same node as Jane is going to get the "next"
node-rev num, beyond the deleted one.
Received on Sat Oct 21 14:36:25 2006