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

Re: "svn diff" and "svn merge" sittin' in a tree

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-02-15 18:29:05 CET

"Sander Striker" <striker@apache.org> writes:
> Actually no, that's not stretching it. There is a common ancestor.
> What you have is:
> REPOS and WC both come from editing the BASE.

Yes, I'm not denying that there *is* a common ancestor. What I'm
saying is, we don't actually have that common ancestor present during
a merge; we don't use it! All *three* of the files involved in the
merge are descendents of that common ancestor.


   branch BAR was started off FOO at FOO:12

   therefore common ancestor is FOO:12

   say that latest trunk descendent is FOO:25

   say latest branch descendent is BAR:13 (i.e., there have been at
                                          least 12 changes in branch

We'll use that setup in the example below...

> > In a merge, we don't usually
> > want *all* the changes between some genuine common ancestor and its
> > descendant (cousin to our target) applied to our target. We want a
> > certain subset of those changes, a range, and this is the ability CVS
> You want the non conflicting changes, and the ability to choose between
> the conflicting ones.

Are you saying that about the range I described, or about *all* the
changes between a true common ancestor and the second merge source?

We want to merge the BAR:7-->BAR:13 changes into our local version of
FOO:25 (assume we have no local mods, not that it matters).

Now, there may be changes between BAR:1 and BAR:7 that *conflict* with
changes between FOO:12 and FOO:25, and yet they will not cause us a
problem when we merge, so long as the BAR:7-->13 changes still apply
cleanly in FOO:25.

Now, BAR:7 is not an ancestor of FOO:25. BAR:1 is a true common
ancestor of both FOO:25 and BAR:13, but BAR:1 is not used in the
merge, BAR:7 is.

I feel like I'm going slowly insane. What am I missing here? The
merge is simply not using a common ancestor, it's using cousins.

> The merging rules are quite simple (assume that changes are on
> 'synchronized' locations in the following):
> - The parts where there are no changes between OLDER, YOURS and
> MINE are copied verbatim.
> - If there is a change between OLDER and YOURS, but not between
> OLDER and MINE, the change is non conflicting and goes in (the
> change made between OLDER and YOURS that is).
> - If there is a change between OLDER and MINE, but not between
> OLDER and YOURS, the change is non conflicting and goes in (the
> change made between OLDER and MINE that is).
> - If there is a change between OLDER and YOURS _and_ the exact same
> change is present between OLDER and MINE, the change will go
> in (since it is non conflicting)
> - If there is a change between OLDER and YOURS and there is a
> different change between OLDER and MINE, we have a conflicting
> change that will have to be resolved by the user (this is where
> conflict markers come in).

Right, that all makes sense, but the thing is, none of it requires
that OLDER be a common ancestor of MINE and YOURS. The same set of
rules works equally well if OLDER is an ancestor of YOURS, and a
sibling/cousin of MINE.



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:08 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.