[cvsnt] Mergepoint issues on b2382

Gerhard Fiedler lists at connectionbrazil.com
Mon Jan 15 11:45:42 GMT 2007

Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.

Andreas Krey wrote:

    |          |
    |          |
    |          |
    +----->  Get more features into branch
    |          |
   1.3  Branch and head evolve further
    |          |
   1.4 <-------+     Merge back into head, using patch
    |          |
   1.5  Branch and head evolve further
    |          |
    +----->  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 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 (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
> (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

> 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)
>     +----->  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 merge, of course.) Something like
>>   cvs up -j tagBranchStart -j branch 
> No. After the merge to 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. 


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook