[cvsnt] Re: Branch merging - this seems wrong...

[Andreas Krey]

On Wed, 07 Jun 2006 09:30:28 +0000, Gerhard Fiedler wrote:
> Andreas Krey wrote:
...
> > B2 ist the *result* of the merge of B1 and A3, thus all changes
> > on the way A1->(B0)->B1 *and* all changes on the way A1->A2->A3
> > are present in the revision B2, plus what was needed to resolve
> > conflicts.
> 
> Yes, B2 of course /contains/ all desired changes, but that's not what merge
> points are about. Neither are merge points about common ancestors. Merge
> points are about /differences/. 

It's a bit hard not to get confused on the terminology. cvsnt's
merge points are firstly a record like 'mergepoint: 1.15.4.3'
on a specific revision (here 1.18), and together they form
what I call a merge arrow from 1.15.4.3 to 1.18. This is an
indication that some part of the changes were transferred to
(merged into) another branch.

> If you say "use B2 as merge point for the final merge of B3 into A(4)",
> this is equivalent to saying "merge the difference from B2 to B3 into A(4)"
> -- which obviously isn't what you want.

Hope I didn't say it. :-( Let's clarify. First, you cannot just merge
two revisions of a file; you need a third, baseline, revisions. I should
have called that the merge base, not merge point; and in plain cvs
it is either the branch root, or the revision from the second -j.

This is also the default in cvsnt, except when very specific merge points
are found.

Also, the baseline revision for the final merge (of A4 and B3) is
obviously A3, not B2.

> Merge points work just fine, though, for all the successive merges from A
> to B. Say you merge A2 into B. This merges the change set A2-A1 into B and
> creates a merge point at A2 for branch B. Then you merge A3 into B. This
> merges the change set A3-A2 into B (because A2 is the most recent merge
> point for B on A) and creates another merge point at A3 for branch B. And
> so on.

Yes. But they also work for merges in the other direction because
the revision resulting from the merge is actuall independent of
which branch is the source and which branch is the destination.
In:

> >     A3       |
> >     |        |
> >     *------->B2    # Merge A up to A3 into B (and commit)
> >     |        |
> >     A4       B3    # More independent work

if I merge either direction, I always have A3 as the baseline revision and
A4 and B3 as the two others. Merging the changes from A3 to A4 into B3
produces the same result as merging the changes from A3 to B3 into A4:
merging is a symmetric operation.

Properly obeying the merge arrows also allows a lot of bookkeeping-free
merging between more than two branches.

...
> I really think that both approaches (Tony Hoyle's comments about merge
> points and our need to have temporary development branches that stay in
> sync with the main development branch) converge in my suggestion to only
> merge from A to B, and after the final merge from A to B, /copy/ B to A.

When we're going to abandon B afterwards this is a valid workaround
(and the reason for that is the symmetry mentioned above).

Continuing to merging from A to B, however, will lead to false conflicts,
because cvsnt doesn't know that everything from B is also in A and will
merge it right back into B.

> This way, merge points work as they should: all merges are from A to B, and
...
> the feature B. So -- just take this code and put it on A, without merging.
> Due to having merged in /all/ changes from A (and this is of course
> crucial!), there is no need to /merge/ B back to A; this is a copy.

I think you could as well do (in A) a
'cvs update -jB_after_merge -jB_before_merge'. :-)

...
> This kind of looks like a merge, but it isn't, conceptually. It's simply
> making the tip of A identical to the tip of B.

Merging back and forth amounts to that effect.

Actually, we also got burnt by this problem, had a look in the code,
and reinstated the way it was before, so for a merge the merge points
in both directions are obeyed.

Andreas

-- 
np: 4'33