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 firstname.lastname@example.org.
I have a question about the behaviour of merges in CVSNT. Client (Linux) is CVSNT version 2.5.03 (Scorpio) Build 2260 (client/server). Server (WinXP) is CVSNT version 2.5.03 (Scorpio) Build 2260 (client/server). Suppose HEAD is the stable code. I want to do some development changes to a.c on a development branch b1, and when done and tested, merge the changes on b1 back to HEAD. The development will take some time, so as I go I want to merge any changes made after the branch point on HEAD across to b1. Say a.c is at version 1.3 on HEAD. I create branch b1 and commit it: cvs tag -b b1 a.c Make some changes on b1, and commit them: <edit> cvs commit -m "First changes on branch" a.c ---> commits version 184.108.40.206 Now someone else changes HEAD to give version 1.4. I want to merge those changes to my branch: cvs update -j HEAD a.c <check, resolve any conflicts> cvs commit -m "Merged from HEAD" a.c ---> commits version 220.127.116.11 Someone else makes another change to HEAD to give version 1.5 - again, I want to pick it up: cvs update -j HEAD a.c <check, resolve any conflicts> cvs commit -m "Merged from HEAD again" a.c ---> commits version 18.104.22.168 As expected, this uses the mergepoint and only applies the changes made between 1.4 and 1.5. So far so good. Now let's take the simplest case - I am now happy with the b1 changes and want to merge back to HEAD. So I do cvs update -A a.c cvs update -j b1 a.c I would *expect* this to use the mergepoints to recognise that b1 already contains all of HEAD's changes from 1.3 to 1.5, and thus that HEAD 1.5 is now the common ancestor. In fact, if HEAD has not had any more commits since 1.5, this "merge" should just be a trivial copy of 22.214.171.124 across to HEAD. However, what it *does* do is apparently to ignore the merge history and to treat the branch point (1.3) as the common ancestor, attempting to merge *all* of the changes on b1 between 126.96.36.199 and 1.3 to HEAD. Thus it effectively tries to merge HEAD's changes from 1.3 to 1.5 back onto HEAD with the expected conflicting outcome. I thought this was what mergepoints were supposed to avoid? I guess I can work around it by some sort of complicated tagging operation before and after each merge... but that's calling for a lot of manual labour that I expected CVSNT to handle for me. This seems like a very basic, common, merge requirement - am I misunderstanding something here, or doing something stupid? -- Tony