Re: Multiple streams of development? A feasible branching approach?

[Derek R. Price]

That looks like an infinite regression of cascading branches you've set
up.  Notice that you can never get a branch directly off the trunk again in
your scenario, at least not without extra work.  Well, not unless you get
down to a single development track for some period of time.  At the least
this will probably turn into unmanagable revision numbers over time.

One common practice is to maintain the current release on a branch, since
it usually undergoes less frequent changes.  In this scenario, the release
planned farthest in the future is always on the trunk:

-------------------------------------- <X+3
       |<X      |<X+1      | <X+2
       |        |          |
       -----    -----      -----

Then when a change is made to any lower branch, the change must be merged
forward onto all others (in this case three times if the change is a bug
fix on the current release), but you won't need to worry about merging
changes twice.

Derek

P.S.  I think with your current development model, CVS will merge for you
with warnings like "some changes were already contained in version 1.X",
but I've never tried it on a large scale.  I'd still switch over to the
model above rather than counting on it.  And you'll avoid the cascading
revision numbers too.  Who wants to look at a CVS status command some years
down the road and try and decipher version
1.4.2.38.2.4.2.6.2.56.2.56.2.1.2.8.2.1.2.18.2.9.2.13.2.5.2.7.2.12.2.1.2.1.2.9?

--
Derek Price                      CVS Solutions Architect ( http://CVSHome.org )
mailto:address@hidden     OpenAvenue ( http://OpenAvenue.com )
--
There are two major products to come out of Berkley: LSD and UNIX.  We don't
believe this to be a coincidence.

address@hidden wrote:

> Our project is organized into multiple overlapping streams of
> development. At anytime there are at least two streams and as many as 4.
> (We are doing this, you may have guessed, because we are in a hurry.
> Please nevermind whether this is, in itself, is a good thing.)
>
> Would anyone care to comment on whether the following branching scheme
> will work:
>
> The trunk would be used for building the current stable release and
> doing relatively simple bug fixes. Call this release X. We would create
> a branch for release X+1 off of the trunk. Bugfixes would be merged
> perioically from X to X+1. When code for X+2 is ready to be checked in,
> we would branch off of X+1. Periodically, bug fixes (originating on the
> trunk) and new code would be merged from X+1 to X+2. If a new concurrent
> release starts up, X+3, we would branch off of X+2 and merge perioically
> from it to X+3. And, heaven help us, so on. So far, notice that merging
> is always from a lower to the next higher release.
>
> Now here is the thing I'm not sure will work. When it is time for
> release X+1 to become the current stable release, it will be necessary
> to merge it to the trunk. My concern regards the bug fixes that were
> previously merged from the trunk to X+1. These will become differences
> on the branch (X+1) that will attempt to get merged into the trunk
> (where they originated). My concern is that these differences will
> result in merge conflicts. I will shortly try this out on a test
> project, but I'll be a little wary that what seems to work OK on a
> little test project won't work on a project consisting of hundreds of
> thousands of lines of code.
>
> Well, if you've been patient enough to follow along with me so far, do
> you think this scheme will work? And, possibly more important, if not,
> can anyone suggest a better approach?
>
> Many thanks in advance.
>
> --Chuck