Hi Martina,
I doubt that merging from newer releases to older releases would work
for us, mainly for the reason that you allude to. If we did that, we
would be merging new features into old releases (even into our current
productiuon release), even before the new features were robust and fully
functional. The other way around is almost always applicable. Any bugs
found in the production release, are merged down into streams still in
development. And, new and evolving functionality in development stream R
is merged appropriately into development stream R+1.
Chuck
> -----Original Message-----
> From: Oefelein, Martina [mailto:Martina.Oefelein@dionex.com]
> Sent: Tuesday, April 10, 2007 11:01 AM
> To: Irvine, Chuck R [EQ]; users@subversion.tigris.org
> Subject: 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:20:23 2007