Greg Stein <gstein@lyra.org> writes:
> On Thu, Mar 08, 2001 at 12:17:21PM -0500, Jim Blandy wrote:
> > Karl Fogel <kfogel@galois.ch.collab.net> writes:
> > > Ahh. I *think* I understand now. Jim, in that example I posted:
> > >
> > > Jane starts a Subversion txn 0.
> > > Bill starts a Subversion txn 1.
> > > Jane makes a change against 3.7 in txn 0, creating node rev 3.8
> > > Bill makes a change against 3.7 in txn 1, creating node rev 3.8.1.1.
> > > Jane aborts her txn, node rev 3.8 is removed from the database.
> > > Bill commits his txn, node rev 3.8.1.1 is committed for all time.
> > > =====> Now 3.8.1.1 exists, but 3.8 does not
> > >
> > > there isn't a "hole", and won't be a hole in the future, because no
> > > two-component noderev ID of the form 3.N (where N >= 8) will ever be
> > > created after the above scenario has happened.
> > >
> > > However, it is not a problem that, say, 3.10 can never exist.
> > > Revisions of that node after 3.7 will be on some 3.8.X branch, and
> > > that's just fine. It's not like "branch" in this context has anything
> > > to do with user-visible branches (i.e., copies). Relatedness distance
> > > between node revisions, for whatever it's worth, can still be computed
> > > according to the formula given in structure.
> > >
> > > Is this an accurate summary?
> >
> > Yes.
>
> Huh? You sure?? ... I thought you would end up with 3.8 and 3.7.1.1. Bill's
> change is *not* derived from 3.8.
>
> Therefore, you'd end up with 3.7 and 3.7.1.1. I would presume that further
> changes occur on the 3.7.1 line.
>
> There are still no holes, but I don't think the above numbering is correct.
Yes, Greg is right. I didn't look at Karl's numbers carefully enough.
3.7.1.1 is an immediate successor of 3.7. Bill's change in txn 1
would create 3.7.1.1, not 3.8.1.1.
How, you may ask, does Bill's transaction "know" to create a branch of
3.7, instead of working from the youngest node in the line, 3.8?
Well, 3.7 is the node that appears in the base revision of Bill's
transaction. Whenever you clone a node revision (i.e., make a mutable
successor of a node revision in some transaction which had previously
been immutable and shared with the txn's base revision tree), you
create an immediate successor of that node revision. If you look at
svn_fs__new_successor_id, the function that chooses an ID for a new
immediate successor of an existing node revision, you'll see that if
3.8 isn't taken, it'll use that as a successor to 3.7, but if 3.8
already exists, it'll make a new revision on a branch 3.7.N.1.
Karl's correct that branches in node revision ID's have nothing to do
with branches at the user level.
Received on Sat Oct 21 14:36:25 2006