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.
It's not much more complex. The general rule is, if the thing you
expected to find isn't there, you always have a formula that tells you
what to look for instead. Does that make sense?
-K
> On 5 Mar 2001, Karl Fogel wrote:
>
> > Jim Blandy <jimb@zwingli.cygnus.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 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.
> >
> > I don't see any problem with 3.8.1.1 existing even though 3.8
> > doesn't.
> >
> > -K
> >
Received on Sat Oct 21 14:36:25 2006