Re: Suggestions for merging system?

[Mike Castle]

On Wed, Dec 06, 2000 at 07:55:51AM -0600, Richard Cobbe wrote:
> 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.

It's more of a hassle not to, isn't it?   This is what I do:

cvs up # on a branch
cvs tag merge_from_branch_foo_to_trunk_3
cvs up -A # onto main branch
cvs up -kk -j merge_from_branch_foo_to_trunk_2 -j 
merge_from_branch_foo_to_trunk_3
# check for conflicts, necessary testing, etc
cvs commit -m "Merged changes from branch_foo from _2 to _3"

If I'm feeling paranoid, I'll do pre and post tags on the main trunk as
well so I can back out any changes, but it's rare that I need to do that.

Heck, in some cases, I've done 30 or so merges like that before shutting
down a branch.  Granted, the further away the two branches get, the more
likely that you'll see conflicts, but it's rarely that bad unless you start
renaming files and stuff.

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

It's not that difficult to add "-r branch" to "cvs co".

> 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

Well, *someone* has to be on a branch.  Either the main one or the bug fix
version (if not both).

One thing I do a lot is keep 2-3 different copies of the source code
checked out.  Main branch in one directory, and one or two old branches for
bug fixes (and merging as mentioned above).  It's not like they have to be
in the same top level directory (at least if your build procedure is done
well).  So rather than doing check outs, I just change directories, do a
cvs up (just to make sure) and then get to work.

> 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

Hint:  Don't let developers branch on just some directories.  Since you
have a single project, have the developers branch the entire thing, even if
they are only going to be changing one file out of 1000.  It's a simple
rule that does help keep things straight.

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  address@hidden  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen