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

RE: RE: RE: Release Branches / 3-plus Development Streams

From: Irvine, Chuck R [EQ] <Chuck.R.Irvine_at_Embarq.com>
Date: 2007-04-20 00:27:20 CEST

I don't understand a couple of things about branch/merge scheme. If all
releases are developmented on branches, what is the trunk really being
used for? Secondly, what do you mean that you keep the trunk pristine?
By pristine I might think you mean "unchanged" but that can't be right
since you are merging changes to the trunk

Chuck

> -----Original Message-----
> From: Daniell, Casey B [mailto:Casey_Daniell@reyrey.com]
> Sent: Thursday, April 19, 2007 2:30 PM
> To: users@subversion.tigris.org
> Subject: RE: RE: Release Branches / 3-plus Development Streams
>
>
> 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
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 20 00:27:50 2007

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