[cvsnt] Merging across several child (bugfix) branches

[John Hall]

"Vitaly Kouzin" <kouzin at infotecs.ru> wrote in message 
news:mailman.18.1155561780.3158.cvsnt at cvsnt.org...

> We have been using mergepoint-based merging for about a year, but now
> we seem to run into a sort of problem when trying to maintain several
> versions of our product.
>
> Client/Server: Concurrent Versions System (CVSNT) 2.5.03 (Scorpio)
> Build 2382.
>
> Consider the following scenario. We develop a project in the trunk.
> When time comes to release version 1.0, we create a separate branch
> for it, say b1, continue development in the trunk towards version 2.0,
> and from time to time merge bug fixes from b1 to the trunk. Then to
> release version 2.0, we create another branch, b2. Now we have to
> support both 1.0 and 2.0, which means fixes made in b1 should be
> applied to b2 as well.
>
> This is where the problem arises: when I try to merge b1 into b2,
> CVSNT merges changes not from the nearest [b1->trunk] mergepoint but
> from the b1 branchpoint, which results in a lot of conflicts.
>
> Is it possible to merge b2 to b1 using the correct mergepoints? And
> more, what is the best strategy of propagating code changes across
> different bugfix branches?

Vitaly,

This has come up before, and the poster was told that this is the expected 
behaviour. I can't quite see why CVSNT couldn't work out the correct merge 
to do, but then I'm no expert.

This is a problem I, too, recently encountered. I ended up writing a perl 
script that walks the tree and does a 'cvs log' per file, works out whether 
the a merge has already been done from b1 to b2. If so, it just issues a 
'cvs update -j b1 filename', if not it finds the last mergepoint on the 
trunk from b1 (I'll call it mergepoint, which is a revision on b1) and 
issues 'cvs update -j mergepoint -j b1'.

The script is very slow, since it issues two cvs commands per file, and also 
doesn't support files added to branch b1, but it does work. For us, the 
number of commits to b1 will be fairly small now that we have b2, and will 
decrease to zero over time, so I can cope with the deficiencies of this 
approach.

Cheers,
John