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.
Glen Starrett wrote: > FWICT, CVSNT handles that rather handsomely. I did some experimentation [...] > You'll notice the "mergepoint" fields in all records where I did a merge, > and the mergepoint record always contains the "from" version that was merged > in (the record already has the "old" and "new" of the file being merged). The mergepoint records are, indeed, correct. Unfortunately, what is wrong is the delta that is being applied during the merge operations. Here is what happens in detail: (Caveat: it's late at night, mergepoint processing is fiddly, and I may well have cocked this up.) Create a file (revision 1.1) Branch it (branch 1.1.2) Create revision on the mainline (1.2) Create a revision on the branch (1.1.2.1) Merge mainline to branch and commit it (1.1.2.2, mergepoint 1.2) Add a revision on the branch (1.1.2.3) Add a revision to the mainline (1.3) On the mainline, perform a merge from branch. This is what I get with the last build of CVSNT under Linux (I can't build the current cvs tree under Linux, so it's quite an old build - maybe the behaviour is different in the latest Windows build - I can't test it 'cos I'm not at work): cvs update -jbranch c RCS file: /home/pgr/cvsnt-test/merges/c,v retrieving revision 1.1 retrieving revision 1.1.2.3 Merging differences between 1.1 and 1.1.2.3 into c rcsmerge: warning: conflicts during merge C c Ignore the merge conflict stuff for now: what is important is that the delta from 1.1 (the branch point) to 1.1.2.3 is being applied to 1.3. This is wrong - 1.1.2.3 includes the delta from 1.1->1.2, and this is now being reapplied to the mainline, which, unsurprisingly already includes this particular delta. The best you can hope is that CVS will notice this and not do it. In the worst case, it will reapply the change. The delta should probably be 1.2->1.1.2.3. This is made up of two bits: 1.2->1.1.2.2 is the change to the mainline required to bring it to include the branch contents as of version 1.1.2.1 *and* include the mainline up-to version 1.2. 1.1.2.2->1.1.2.3 is the change needed to include all development since the last mainline-to-branch merge. [Btw, it can't be 1.1.2.2->1.1.2.3 since this misses the change from 1.1->1.1.2.1.] If you look at the conflicts, you find that the stuff added at revision 1.2 appears in both branches of the merge conflict (i.e., it has been reapplied). Now, do the merge from from 1.2->1.1.2.3 on to 1.3 by hand (-j1.2 -jbranch) You still get a conflict, but the conflict is now the "correct" one. CVSNT should, in principle, be able to work out that "1.2" is the revision to use - it has it recorded. (Btw, it isn't always this simple, but the information is, in all the cases I've looked at, available.) Time for bed said zebedee... phil -- change "spam"/"news" to "phil" to email me