[cvsnt] Branch merging - this seems wrong...

[Tony Eva]

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
1.3.2.1

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
1.3.2.2

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
1.3.2.3

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
1.3.2.3 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 1.3.2.3 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