[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: delta metric

From: Brian Moore <mooreb_at_epinions-inc.com>
Date: 2001-03-05 23:34:11 CET

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.

b

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.