Yes, this is currently what we're doing NOW, in my current
company with SVN. We have development branches, and merge
from R1-to-trunk, then trunk-to-R2, and ..to-R3 if it exists.
Note in addition to branches, we create tags which ease or
merging. Read up on tags if you have not yet.
>-----Original Message-----
>From: Daniell, Casey B [mailto:Casey_Daniell@reyrey.com]
>Sent: Monday, April 23, 2007 10:51 AM
>To: Irvine, Chuck R [EQ]; users@subversion.tigris.org
>Subject: RE: RE: RE: Release Branches / 3-plus Development Streams
>
>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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 23 17:01:19 2007