[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Release Branches / 3-plus Development Streams

From: Irvine, Chuck R [EQ] <Chuck.R.Irvine_at_Embarq.com>
Date: 2007-04-19 17:05:04 CEST

This is a repeat of a previous mailing list posting. Pardon the repeat,
but no one responded and, since it is a pretty question for us, I thouht
that I would try again. Thanks.

.....

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
Received on Thu Apr 19 17:05:30 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.