[cvsnt] Mergepoint issues on 2.5.0.3 b2382

[Gerhard Fiedler]

Andreas Krey wrote:

> Yes, but that is true in any case of merges -- they don't always work
> automatically, and it may be some work to actually make a correct merge
> of all the functions from both source paths. But if you do that, then
> a merge arrow is in order; if you don't (as in the case described
> previously where you only take over selected functionality), then
> placing a merge arrow is incorrect.

I agree with this. I'm only talking about what we both seem to consider a
"correct" merge (one that deserves a merge arrow, one that completely
integrates functionality from both code lines).


>> There is a solution (unidirectional merge, with a branch copy at the
>> end) that provides all the benefits without the dangers of running such
>> back-and-forth merges.
> 
> This is a jump to the wrong conclusion. In our scenario we hade a branch
> into which we merge from the head and placed merge arrows accordingly.
> To get the branch work into the head we now have two choices: Do a
> backmerge into the head, or do a merge from the head into the branch
> and then copy the branch contents into the head. Assume the situation:
> 
>    1.1---------+
>     |          |
>     |       1.1.2.1
>     |          |
>    1.2      1.1.2.2
>     |          |
>     +-----> 1.1.2.3  Get more features into branch
>     |          |
>    1.3      1.1.2.4  Branch and head evolve further
> 
> Now we are going to do it your way. We merge into the branch again
> and then copy the branch into the head:
> 
>   (1.3      1.1.2.4  Branch and head evolve further)
>     |          |
>     +-----> 1.1.2.5  Get more features into branch
>     |          |
>    1.4 <=======X     Do copy outside cvsnt.
>     |
> 
> For the merge we merge the diff from 1.2 to 1.3 into 1.1.2.4, yielding
> 1.1.2.5 which we then copy as 1.4 onto the head.
> 
> Now, if we are doing it my way (patched cvsnt), then we simply do
> a backmerge:
> 
>   (1.3      1.1.2.4  Branch and head evolve further)
>     |          |
>    1.4 <-------+     Merge back into head, using patch
>     |          |
> 
> This backmerge goes to merge the diff from 1.2 to 1.1.2.4 into 1.3,
> again yielding 1.4.

How does this continue? (Below you said that one of the differences between
the merge-back-and-forth approach and the merge-forth-copy-back approach is
that the branch can or can't be used...)

>    1.1---------+
>     |          |
>     |       1.1.2.1
>     |          |
>    1.2      1.1.2.2
>     |          |
>     +-----> 1.1.2.3  Get more features into branch
>     |          |
>    1.3      1.1.2.4  Branch and head evolve further
>     |          |
>    1.4 <-------+     Merge back into head, using patch
>     |          |

For further development on the branch, you need to get the 1.3
functionality on the branch. Let's also consider that the back merge
created a number of conflicts that had to be resolved, like taking code
out, some reorganizing and everything we agreed upon earlier that may
happen in a merge.

So, after the merge that created 1.4 (and maybe after some additional work
on both trunk and branch), you run again a merge from trunk to branch. How
does this work? Looks messy to me.


> Thus, merge forward and copy back produces the *same* result
> in the head as the merge-back-with-patch whose common
> ancestor selection Tony declared bogus.

Maybe in the head; I'm not sure. But it definitely doesn't produce the same
result on the branch.


>> I fail to see the actual problem :)
> 
> The only difference is that, after the merge-forward-copy-back,
> the branch is in a state where it can't be used anymore. 

Why is this? We started out considering a scenario where one has a branch
that one wants to keep up-to-date with the trunk while implementing a
feature on the branch. So this line, right before the copy-branch-to-trunk,
would be necessary anyway: 

>     +-----> 1.1.2.5  Get more features into branch

After this line, the branch has all features from trunk plus the new branch
feature. So I can copy it to the trunk, if I want the branch feature there.
There's nothing that prevents me from continuing development on the branch,
say to enhance the new feature.

> And the copy-back is an operation that cvsnt does not provide and has to
> be done manually. 

I don't think this is correct. If you mean by "done manually" that one has
to use a command line command, you are correct. You could use a cvs update
command on the trunk to merge in the complete branch, from (branch) start
to (branch) tip. (After the 1.1.2.5. merge, of course.) Something like

  cvs up -j tagBranchStart -j branch 

run on trunk does the copy-back-to-trunk. It needs a branch start tag,
which is a good thing to have anyway. It also can be repeated after having
been done once, if one tags the branch at this merge (also a good thing to
do anyway) and uses now this new tag as start reference.

Gerhard