Brian Moore <mooreb@epinions-inc.com> writes:
> i hope that the statement "3.10 cannot exist unless 3.8 does" is false,
> because that means if there's a hole (as described earlier today)
> in the revision tree, development must stop on that branch, unless i
> totally misunderstand how the revision numbers are assigned.
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?
-K
> On 5 Mar 2001, Jim Blandy wrote:
>
> > Brian Moore <mooreb@epinions-inc.com> writes:
> > > so if revision 3.8.1.1 exists but revision 3.8 does not exist,
> > > will the merge from 3.8.1.1 to 3.10 work properly? i'm thinking
> > > that finding a common ancestor will not be as simeple as i thought
> > > it would be.
> >
> > 3.10 cannot exist unless 3.8 does.
> >
Received on Sat Oct 21 14:36:25 2006