[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suggestions for merging system?

From: Stephen Cameron
Subject: Re: Suggestions for merging system?
Date: Wed, 6 Dec 2000 06:46:44 -0800 (PST)

Richard Cobbe wrote that he wanted suggestions about merging...

I can tell you what we do, and you can see if it might make sense
for you.

We do all development and bugfixes on branches.  We don't really use
the trunk for any development at all.  We have "official" branches that
everybody knows about, essentially one branch per release.  Bugfixes
for old releases go on the branch for the old release.

Developers are free to create their own branches if they wish to isolate
themselves for a while from the rest of the organization, but if their code
is to see the light of day, they have to eventually merge it into one of
the active "official" branches.  In practice, the developers rarely create
their own branches it seems.

When a new branch is to be created (when development on a new release is 
to begin) the current newest branch is merged to the trunk, then the
new branch is created off the trunk.  Lots of tagging and record keeping
is done just to keep things straight.  (Yes it's a hassle, but necessary,
there's no avoiding it, so just take your time and tag it.)  Typically we have
2 active branches at any given time, sometimes 3, sometimes just 1.

Probably the toughest problem we run into is that occasionally stuff fails to
get merged up from older branches to newer branches.  "cvs rdiff -s" can catch
some of this, (find files on old branches which have been modified since a new
branch was created, but which have not yet been modified at all on the new
branch, and therefore, must not have been merged.)

This problem is probably an artifact of our rather loose development model, in
which it is each developer's responsibiltiy to merge his code changes forward. 

(we do that 'cause there's so much code, no one person could hope to be able to
merge it all and sensibly resolve the conflicts.)  One person *can* go thru the
motions of the merge, at least to see what a full-repository merge *would* do,
in order to catch things that developers forgot to merge...)

Well, that's one way it can be done, we've done it that way for the last 3
years or so.

Hope it helps.

-- steve

Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]