I think this is why I like developing on a branch, rather
than on the trunk - it just seems more natural to me anyway.
We tag the trunk code for releases, and release the tag.
Only bug fixes, and not features, are merged to the trunk.
As bug fixes are merged to trunk, they are subsequently
merged to all the branches. We run regression on trunk
code for sanitation.
>-----Original Message-----
>From: Irvine, Chuck R [EQ] [mailto:Chuck.R.Irvine@Embarq.com]
>Sent: Tuesday, April 10, 2007 12:20 PM
>To: Oefelein, Martina; users@subversion.tigris.org
>Subject: RE: Release Branches / 3-plus Development Streams
>
>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
>
---------------------------------------------------------------------
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:40:20 2007