Re: Suggestions for merging system?

[Dale Miller]

Richard Cobbe wrote:

> Greetings, all.
>
> I'm trying to come up with a better model for managing merges and branches
> than that which we currently use with our CVS repository at work.
>
> First, a brief description of the structure of our working area.  We're
> working on a single software system which consists of a number of
> executables and shared libraries.  The source code for each of these
> binaries is stored in a separate directory in a large tree.  The entire
> tree is administered by CVS.
>
> All of the documentation I've read (both the Cederqvist and the Fogel book)
> seems to assume that the trunk is for active development, and side branches
> are primarily for fitting bugfixes into previously-released versions of the
> software system.  At work, we do this the other way.  Now, cvs can
> obviously merge in both directions, but there are some difficulties with
> our current set-up.
>
> After we complete a release, we can shut down bugfixing on the previous
> release, retiring that branch.  Since, however, that branch is in fact the
> trunk, we have to "retire" this "branch" by merging the current state of
> the active branch onto the trunk.  This will work, but if we've done any
> prior merges from the trunk to the branch, then merging the other direction
> is going to cause a lot of conflicts.  (We could avoid these by being
> clever with tags and doing many separate merge commands, but that's rather
> a hassle.)  In addition, this makes it very difficult to continue
> development on that "branch" should it become necessary at a later time.
>
> The other alternative, of course, is retiring the trunk, and doing all
> subsequent development on the branch.  That's pretty ugly; it makes life
> difficult for new folks trying to check out a copy of the repository for
> the first time; and I'd like to avoid it if I can.
>
> So, I'd like to recommend swapping the two: the trunk should be our main
> development effort, and the branch our bugfix area.  However, the fact that
> the currently-stable version of our software will be on branches makes it
> somewhat more difficult to get a copy of the software for building a bugfix
> release, especially if the various subdirectories have branched
> independently, as we now have to worry about making sure each directory was
> checked out from the right branch.  (Unfortunately, doing each of the
> branches at the root of the project wouldn't really help, especially since
> many of the branches would be rooted at unstable points in various
> subdirectories.)
>
> Has anyone found a successful way to handle this situation?  I'd like to
> preserve the ability of individual developers to branch their sub-projects
> as necessary.
>
> Now, we could create a shell script to do the necessary cvs checkout and
> update commands separately in each directory, place this script under CVS's
> control, and have the developers update the script whenever we do a
> branch.  This is the only possible solution I've been able to find, and I'm
> still hoping there's a better alternative.
>
> I'd greatly appreciate any suggestions and advice.
>
> Thanks in advance,
>
> Richard

Richard,

I am in the process of migrating from CMVision to CVS for a major project.
I have written conversion routines so that I maintain all versions, dates,
and history.  Now I am working on a user interface program for the
developers to use.  The following is extracted from a System Change
Request (SCR) form that I wrote for the migration that details what I
am doing for the developers to interface with CVS and it may give you
some ideas:

 ._._._._._._._._._._._._._._._._._._._._.
USER INTERFACE:
All baseline changes will be tracked to SCRs.

Branching will be used as the centerpiece of the development environment that
enables multiple developers to work on the same or different parts of the
software at the same time.  Changes will be tested using the branch tags with
the branch being merged to the main after testing is complete.

The cvs front-end program will create cvs_stage work areas by SCR and will
execute the cvs commands for the developers.

When a developer wants to begin work on a SCR, the worker will enter the SCR
number.  If the number is of an active SCR a cvs_stage directory will be
created under the user's home directory of SCRyyyynnnn.

Developers will use the interface program to "checkout" or "fetch" files for
the SCR.  The program will use the cvs rtag command to create a branch for any
file being checked out for edit.  (Note that CVS does not actually mark the
file in the repository as being checked out).  Files being "fetched" will not
have a branch made and will be set to read only.

The program will make the branch in the repository using:
cvs rtag -b -r HEAD SCRyyyynnnnb path/filename

HEAD is the tag that CM applies to the latest functional set of files on the
repository. SCRyyyynnnnb is the descriptive name of the developer's branch
(note the "b" to denote a branch).

The program will checkout files using:
cvs checkout -r SCRyyyynnnnb path/filename

The program will fetch files using:
cvs -r checkout path/filename

The developer will edit the "checked out" files. When the developer has
finished with the SCR work a cvs commit must be done to update the repository
branch. However, before the commit is done, the worker should resynchronize the

work area with any changes that may have been made to the baseline.

The program will resynchronize the work area using:
$ cvs update -j HEAD

This scans the developer's files and merges in any changes made to the baseline

while they have been working on their SCR. CVS will mark any unresolvable merge

conflicts, which should be resolved manually and re-committed.

The program will commit the changes using:
cvs commit -m"SCRyyyynnnn" path/filename

The -m option is the log message option.  This will record the SCR number to
the commit.  The program will then rtag the SCR number to the version that was
just updated using:

cvs rtag -F -r rev SCRyyyynnnn path/filename
The rev will be the revision number from the commit and the -F will move the
tag if it already exist (in the event the filename had previous commits for the

SCR).

Once the developers work on the SCR is complete and the branch is synchronized
with the baseline, the developer using the interface program will notify the
WPL|TEST|CM that the work is done and that it should be system tested.

CM will verify that the SCR branch includes any changes from the main trunk and

will update the IBL build area (using CVS export) with the tagged versions of
the files changed for the SCR.

When a developer is done with a SCR, he can just remove the SCR directory
structure from the cvs_stage area. The interface program will execute the
commands needed.

The interface program will use two supporting data files that are created from
perl programs.  One file contains the phase, SCR number, and title or each
active SCR and is updated from the cmpa as part of the SCR report generator.
The other file contains the list of every directory and file that is in the CVS

repository.  These files are then used to validate SCRs and to generate lists
of files that can be checked out with their entire pathname.  The developers
will checkout or fetch files from a list generated using a perl grep command
against the file list data file.

The interface program will be menu driven with changing menus depending on what

process the developer is doing.

The interface program will include most CVS interaction that a developer would
need.  cvs commands will also be available to the developers outside of the
interface program.  Available programs like cvsweb.cgi can also be used to
browse the contents of the CVS repository.

The interface program will include menu items for:
- setting up a new SCR work area
- listing current SCR work areas with SCR status and title included for active
SCRs, notactive work areas will be identified
- setting to a SCR work area
- showing active SCRs
- fetching files that you need in a work area to support user builds but do not

need to be changed
- checking out files that need to be changed
- updating working area with main trunk
- adding new files
- displaying what files are in a SCR work area
- displaying diffs on files in the work area verses what is in the repository
- notification to others that work is complete
- removing SCR work areas
The interface program will include menu items for CM staff including:
- exporting files for placement in the build area
- moving a SCR branch into the main trunk
- tagging releases of the entire repository
 ._._._._._._._._._._._._._._._._._._._._.

Dale Miller