I worked for a company that also did this, and with CVS.
In that case,
- R+1 was never merged to R
- any fix for R+1 also went to R, if applicable
- any fix for R also went to R+1, if applicable
Since SVN and CVS are basically similar revision
control systems as far as ideology is concerned,
I don't see how SVN can change the approach you
have now.
>-----Original Message-----
>From: Irvine, Chuck R [EQ] [mailto:Chuck.R.Irvine@Embarq.com]
>Sent: Thursday, April 19, 2007 11:05 AM
>To: users@subversion.tigris.org
>Subject: Release Branches / 3-plus Development Streams
>
>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
>
---------------------------------------------------------------------
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:17:57 2007