RE: Release Branches / 3-plus Development Streams

Hi Chuck,

Like you, we have to maintain 3 existing releases concurrently with the trunk. We develop (usually) in the trunk and merge fixes (and sometimes features) to the release branches. If I understand you correctly, you are merging in the other direction, from the oldest release branch to the newer branches and finally to the trunk.

I think both ways will work technically, and the choice is probably more a question of development philosophy and procedures.

ciao
Martina

-----Original Message-----
From: Irvine, Chuck R [EQ] [mailto:Chuck.R.Irvine@Embarq.com]
Sent: Tuesday, April 10, 2007 5:46 PM
To: users@subversion.tigris.org
Subject: Release Branches / 3-plus Development Streams

We have lately adopted SVN as our standard source code mgt tool.

Previously, we used CVS and had a standard approach to branching in the
context of multiple concurrent release development streams. For two
concurrent streams, it was basically what is described in the SVN Book
as "Release Branches". Unfortunately, we are often forced to develop for
3 and 4 releases concurrently. (The SVN book does't comment specifically
on this situation.)

For this situation, our branching model using CVS was basically to
always have the latest release (R) on the trunk. Whenever we started on
release R+1, create a release branch for R and let R+1 development
proceed on the trunk. Graphically, it looks like this:

             /---------------------
            / R1
           /
          / /---------------
         / / R2
        / /
-------/------------/-------------------
R1 R2 R3

We would then merge from R1 to R2, from R2 to R3, etc. Eventually, R
would be deployed to production and R-1 would be retired.

So, here's my question, so we don't go down the wrong track, can any of
the experienced SVN folks comment on the soundness of this approach
using SVN? I've been experimenting with it using SVN and it seems to
work nicely. Any input would be much appreciated. Thanks

Chuck Irvine
Embarq

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 10 18:01:51 2007