[cvsnt] Mergepoint issues on 2.5.0.3 b2382

[Gerhard Fiedler]

Andreas Krey wrote:

   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
    |          |
   1.5      1.1.2.5  Branch and head evolve further
    |          |
    +-----> 1.1.2.6  Get more features into branch - see below


>> For further development on the branch, you need to get the 1.3
>> functionality on the branch.
> 
> But not necessarily immediately.

I meant it was needed. Not for the merge process's sake, but because the
functionality was needed.

>> 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.
> 
> Not really. If you directly merge back into the branch from 1.4 (and
> nothing has been done on the branch since) it actually degenerates
> into a copy. Otherwise 1.1.2.4 is now the effective common ancestor,
> and merges only deal with what has changed in 1.4 on the head (a lot
> and potentially messy stuff from the backmerge) and what changed on
> the branch since 1.1.2.4 (probably very little).

Let's say there were changes in both branches (.5 in the diagram above).

> If 'messy' meant the common ancestor selection: That now is 1.1.2.4
> (as by the diagram above), independent of the direction of the
> next merge.

How does this "grab" the changes that happened between 1.2 and 1.3 when you
merge into the branch and create 1.1.2.6?


> Yes, but you can't properly merge that work into the trunk any more. Nor
> can you merge new trunk stuff into the branch. The situation is:
> 
>   (1.3)
>     +-----> 1.1.2.5  Get more features into branch
>     |          |
>    1.4 <=======X     Do copy outside cvsnt.
>     |
> 
> In 1.4 the head contains everything from the branch so far, but the
> merge arrows don't record that fact.
> 
> If you do a new merge from head to branch, regular cvsnt will merge
> the changes from 1.3 to 1.4 into the branch, although that is exactly
> the work that already has been done in the branch. 

You are correct, I missed this.


>>> 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 
> 
> No. After the merge to 1.1.2.5 there is no need for a merge, the branch
> is in exactly the state you want the head to have (you already merged
> the head with the branch). 

Yes, you are right again... :)  I actually never did it that way, I always
used a three-step approach (copy branch to trunk, add files that are new on
trunk, remove files on trunk that are not on the branch). This merge
command is what Tony H suggested, in that earlier thread, and I thought I
understood it. 


I wish Tony H or Arthur would explain better the situation(s) they have
seen that lead to data loss. IIRC, so far it was only a "trust me on that"
or something the like...  I think it would be extremely helpful if the
situations that lead to data loss were described somewhere in a way that
allows them to be reproduced. 

Gerhard