Re: How to avoid conflicts avalanche

[Chris Sharpe]

On Tue, 26 Jun 2001, Sergiy wrote:

> Our software has different modifications for different countries. Thus
> in our cvs repository we have the main development trunk, and country
> branches. When we cut a new major release on the trunk, we need to merge
> from the trunk to all country branches. These merges result in a large
> number of conflicts. It requires time and significant programming
> efforts to resolve those conflicts.
> 
> One way to avoid this is to do interim merges regularly. The other way
> could be to pursue developers to use some script which automatically
> does the merge to country branches every time they commit to the trunk.
> But they often forget to follow such procedures, and apparently CVS
> doesn't have any way of enforcing this automatically.
> 

We have a similar situation where multiple releases are being
developed concurrently and commits to one branch are required to
be merged into several other branches.

I created a wrapper script 'checkin' which developers are required
to use instead of 'cvs commit'.  Checkin essentially does the
first commit for them, then proceeds to checkout other branches,
merge the code, and do more commits.  If there are conflicts it
aborts, leaving the merge area around with instructions telling the
user to resolve the conflicts and rerun checkin from there.

There are lots of caveats you have to properly handle in the checkin
script (eg. binary files, adds, removes, RCS keywords, etc.) but
this scheme is working well with 150 developers in 6 branches.

It can be quasi-enforced by using 'cvs -s VAR=value' for commit
operations and having the commitinfo script use ${=VAR}.  cvs
will require the variable to be set.  Users could go to the trouble
of figuring out these variables and the correct setting and add
them to their .cvsrc or whatever, but hopefully this would serve
as reminder enough to use the checkin script instead of cvs commit.

You can also enforce this (albiet after the fact) by having a tool
that analyzes the different branches and creates a database of
commits that are in one branch but missing from another.  Then
notify those that still have work to do.

+-------------------------------------------------------------------+
| Chris Sharpe  KF4WVO         Author of "The Unofficial PEZ FAQ"   |
| address@hidden   "PEZ - A treat to eat in a toy that's neat"|
+-------------------------------------------------------------------+