so if revision 188.8.131.52 exists but revision 3.8 does not exist,
will the merge from 184.108.40.206 to 3.10 work properly? i'm thinking
that finding a common ancestor will not be as simeple as i thought
it would be.
On 5 Mar 2001, Karl Fogel wrote:
> Jim Blandy <email@example.com> writes:
> > > 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.
> > Yes, and what kind of problematic node numbers could this situation
> > produce? Give me a specific example.
> Actually, I don't think they are problematic, should have said so up
> front. I was just concurring with Ben that there can be skips in the
> sequence of node revision numbers off a given node.
> 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 220.127.116.11.
> Jane aborts her txn, node rev 3.8 is removed from the database.
> Bill commits his txn, node rev 18.104.22.168 is committed for all time.
> I don't see any problem with 22.214.171.124 existing even though 3.8
Received on Sat Oct 21 14:36:25 2006