The trunk is really being used as a point to merge between releases.
You are correct in assuming that by "pristine" I do not mean totally
unchanged, but rather, only the Config Managers can make changes on this
branch -- all developers must commit on a branch. By doing this we keep
it easy to determine on the initial merges to the TRUNK, what changes
should be kept should a conflict arise.
I think that answers your questions...
Casey
-----Original Message-----
From: Irvine, Chuck R [EQ] [mailto:Chuck.R.Irvine@Embarq.com]
Sent: Thursday, April 19, 2007 5:27 PM
To: Daniell, Casey B; users@subversion.tigris.org
Subject: RE: RE: RE: Release Branches / 3-plus Development Streams
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 Mon Apr 23 16:51:17 2007