I am currently doing almost what your propose, instead we keep the TRUNK
pristine and have all development occur on the R branches. Basic model
is:
Development occurs on the R1 branch and when done, or at a point we need
to promote the changes to other release(s), I merge the deltas from the
start of the branch to the end to the TRUNK. During this merge since all
changes by DEV has occurred on the branch I know to take whatever
changes occurred on the branch.
Then, from the TRUNK I merge the one new revision created from the R1 to
TRUNK merge to the R2 branch. If there was an R3 branch created at the
same times, changes would go out to them as well. If you do this outer
merge you will have to be careful when merge the R2 and R3 branches to
the TRUNK. See the SVN docs on how to do this merge, but you will be
picking the rev that the TRUNK and R2, or R3 branch sync'd and the last
revision on the branch, then merge to the target location. (AKA probably
the TRUNK again)...
Casey
-----Original Message-----
From: Chris.Fouts@qimonda.com [mailto:Chris.Fouts@qimonda.com]
Sent: Thursday, April 19, 2007 10:18 AM
To: users@subversion.tigris.org
Subject: RE: Release Branches / 3-plus Development Streams
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 19 21:30:25 2007