[cvsnt] Merging problems, getting strange conflicts....
Bo.Berglund at system3r.se
Tue May 27 11:39:48 BST 2008
Concerning 2-way merges I am not talking about such. Mu merges are 1-way
only, first from Trunk to Branch and then later another 1-way from
Branch to Trunk.
The sequence is:
- Branch off trunk at say rev 1.8
- Make changes on branch to arrive at 188.8.131.52
- Also change trunk to get 1.11
- Now merge HEAD into branch and resolve conflicts (1-way)
- Commit to get 184.108.40.206
- Now there is a mergepoint set on 220.127.116.11 pointing back to 1.11
- Next try the merge from branch to head (also 1-way) and get the
I always thought that the mergepoints recorded pairs of revisions that
were already merged such that the receiving end had all the changes from
the branchpoint included.
In my case above after the first merge the branch would contain all of
the head changes in addition to the branch changes and this is noted by
Now, in the second (1-way) merge CVSNT should have noted that 18.104.22.168
(tip of branch) already contained all of the head changes from the
original branch point to the HEAD revision 1.11 since the mergepoints
would tell it so.
Consequently there is no need to get any data from HEAD, just copy over
the contents of branch in the merge process.
But what happens is that it announces conflicts where there are same
location changes even though the valid such conflicts were already
solved in the first merge/commit.
So why are the mergepoints not used?
(Sorry about the top-posting, I am doing this from work where
newsreaders do not work and Outlook is not able to format my reply
From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org] On Behalf
Of Arthur Barrett
Sent: den 27 maj 2008 02:02
To: cvsnt at cvsnt.org
Subject: Re: [cvsnt] Merging problems, getting strange conflicts....
> Now my TCPIP branch is working fine and I need to move it to TRUNK. In
> preparation for this I merged HEAD into the branch and solved the
> conflicts (because HEAD had changed a lot less than Branch over the
> months). I thought that by doing this the final merge from branch to
> trunk would be almost automatic.
There was a really long thread on this ages ago. I think Gerhard was
involved in a lot of it and may even have written something up
afterwards in the wiki. The short summary is that CVSNT cannot do
bidirectional merging. I think after that discussion Tony may have made
some changes to the merge code to support a single suggestion that was
made - if I'm remembering correctly then that'll be in 2.5.04 only and I
think your production system is 2.5.03 - but I'm not sure it'd cover
The recommended approach is to merge branch to trunk with no merge from
trunk to branch (you did this as a 'prep' step which is simply
unnecessary since the trunk is not locked or changed until you actually
commit the merge. Alternativly there is the 'copy branch to trunk' or
'make trunk equivalent to branch' method.
cvsnt mailing list
cvsnt at cvsnt.org
More information about the cvsnt