"Sander Striker" <striker@apache.org> writes:
> Actually no, that's not stretching it. There is a common ancestor.
> What you have is:
>
> BASE, REPOS(HEAD), WC
>
> 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.
Watch:
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
BAR)
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.
???
-K
---------------------------------------------------------------------
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