You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ron Bieber <ro...@bieberlabs.com> on 2004/12/03 12:46:05 UTC
Re: Branching best practices (In reply to: Adopting a branch as
trunk)
On Thu, 2004-12-02 at 13:11, Guido Anzuoni wrote:
> > -----Original Message-----
> > From: Scott Palmer [mailto:scott.palmer@2connected.org]
> > Sent: Thursday, December 02, 2004 7:39 PM
> > To: Subversion Mailinglist
> > Subject: Re: Branching best practices (In reply to: Adopting
> > a branch as
> > trunk)
> >
> >
> >
> > On Dec 2, 2004, at 1:22 PM, Jeroen Leenarts wrote:
> >
> > > Wouldn't it be best to let the trunk always be the main line of
> > > development? When a release is made you create a branch tagged with
> > > the version name. (ie. branch/1.0 or branch/2.0) That way
> > no difficult
> > > merging is required since changes to the branches will
> > almost allways
> > > be bugfixes which you usally want to merge on an individual
> > basis into
> > > the main line of development?
> >
> > True...
> > But very often version 2.0 work is started before version 1.0 is
> > complete, so the 2.0 code can't go into a 1.0 trunk yet. I think that
> > is the scenario that Guido has.
>
> Yes, you are right.
The philosophy we use is that the stable ("1.0") version is always
branched and the next version ("2.0") starts in the trunk. With this
said, 1.0 does not necessarily have to be complete in order to branch
it. You can branch it when 2.0 development begins as long as you do
the merging from the 1.0 branch to the trunk that you are already doing
having stable in the trunk and merging over to 2.0.
This will alleviate the need to delete and replace the trunk.
Currently we are on a bi weekly release schedule, however we can
potentially have months of development that go into any one release.
The long term work is done in 'developer' branches (we actually create a
separate top level directory called 'devbranches' for these activity
based branches) by the developer while the actual 'release branches' are
created in the 'branches' hierarchy. When our developers complete a
feature in the 'devbranches' hierarchy they merge it down to the release
branch in which it is to go live and then subsequently merge it down
from the release branch to the trunk for the next release (the "2.0"
version in this example).
It might seem that there is a lot of merging going on, but overall this
has worked very well for us. I hope this helps.
-- Ron
>
>
> >
> > I think that two reasonable options would be:
> >
> > 1)move/rename trunk to branches/1.0 and then move/rename branches/2.0
> > to trunk.
>
> Yes again.
> When I decide to make 2.0 the current trunk, I have already merged in 2.0 branch whatever has
> been produced in 1.0, so my real need is to "replace" prj/trunk with branches/2.0.
>
> Release 1.0 as a line of development (I mean enhancement with new features) will stop, so
> I would
> svn copy http://myserver/repos/prj/trunk copy http://myserver/repos/prj/tags/1.0 (put a label !!)
> svn delete http://myserver/repos/prj/trunk
> svn copy http://myserver/repos/prj/branches/2.0 http://myserver/repos/prj/trunk
>
> When I need to produce a patches for 1.0 line of development I will
> svn copy http://myserver/repos/prj/tags/1.0 http://myserver/repos/prj/branches/1.0 (i.e. the "trunk" for 1.0 line)
> svn co http://myserver/repos/prj/branches/1.0 .
> ...do the patch...
> svn commit....
> svn copy http://myserver/repos/prj/branches/1.0 http://myserver/repos/prj/tags/1.0.1
>
>
> The main stream is always prj/trunk that now "starts" from the work done for 2.0.
>
> Thanks to everyone for all the suggestions,
> Guido.
>
>
> >
> > 2)copy the trunk to branches/1.0 and then merge branches/2.0 into the
> > trunk (and delete branches/2.0 until 2.0 is released).
> >
> > Scott
> >
> >
> > ---------------------------------------------------------------------
> > 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
Re: Branching best practices (In reply to: Adopting a branch as trunk)
Posted by Jeroen Leenarts <le...@tiscali.nl>.
Ron Bieber wrote:
>On Thu, 2004-12-02 at 13:11, Guido Anzuoni wrote:
>
>
>>>-----Original Message-----
>>>From: Scott Palmer [mailto:scott.palmer@2connected.org]
>>>Sent: Thursday, December 02, 2004 7:39 PM
>>>To: Subversion Mailinglist
>>>Subject: Re: Branching best practices (In reply to: Adopting
>>>a branch as
>>>trunk)
>>>
>>>
>>>
>>>On Dec 2, 2004, at 1:22 PM, Jeroen Leenarts wrote:
>>>
>>>
>>>
>>>>Wouldn't it be best to let the trunk always be the main line of
>>>>development? When a release is made you create a branch tagged with
>>>>the version name. (ie. branch/1.0 or branch/2.0) That way
>>>>
>>>>
>>>no difficult
>>>
>>>
>>>>merging is required since changes to the branches will
>>>>
>>>>
>>>almost allways
>>>
>>>
>>>>be bugfixes which you usally want to merge on an individual
>>>>
>>>>
>>>basis into
>>>
>>>
>>>>the main line of development?
>>>>
>>>>
>>>True...
>>>But very often version 2.0 work is started before version 1.0 is
>>>complete, so the 2.0 code can't go into a 1.0 trunk yet. I think that
>>>is the scenario that Guido has.
>>>
>>>
>>Yes, you are right.
>>
>>
>
>The philosophy we use is that the stable ("1.0") version is always
>branched and the next version ("2.0") starts in the trunk. With this
>said, 1.0 does not necessarily have to be complete in order to branch
>it. You can branch it when 2.0 development begins as long as you do
>the merging from the 1.0 branch to the trunk that you are already doing
>having stable in the trunk and merging over to 2.0.
>
>This will alleviate the need to delete and replace the trunk.
>Currently we are on a bi weekly release schedule, however we can
>potentially have months of development that go into any one release.
>The long term work is done in 'developer' branches (we actually create a
>separate top level directory called 'devbranches' for these activity
>based branches) by the developer while the actual 'release branches' are
>created in the 'branches' hierarchy. When our developers complete a
>feature in the 'devbranches' hierarchy they merge it down to the release
>branch in which it is to go live and then subsequently merge it down
>from the release branch to the trunk for the next release (the "2.0"
>version in this example).
>
>It might seem that there is a lot of merging going on, but overall this
>has worked very well for us. I hope this helps.
>
>-- Ron
>
>
>
>>
>>
>>>I think that two reasonable options would be:
>>>
>>>1)move/rename trunk to branches/1.0 and then move/rename branches/2.0
>>>to trunk.
>>>
>>>
>>Yes again.
>>When I decide to make 2.0 the current trunk, I have already merged in 2.0 branch whatever has
>>been produced in 1.0, so my real need is to "replace" prj/trunk with branches/2.0.
>>
>>Release 1.0 as a line of development (I mean enhancement with new features) will stop, so
>>I would
>>svn copy http://myserver/repos/prj/trunk copy http://myserver/repos/prj/tags/1.0 (put a label !!)
>>svn delete http://myserver/repos/prj/trunk
>>svn copy http://myserver/repos/prj/branches/2.0 http://myserver/repos/prj/trunk
>>
>>When I need to produce a patches for 1.0 line of development I will
>>svn copy http://myserver/repos/prj/tags/1.0 http://myserver/repos/prj/branches/1.0 (i.e. the "trunk" for 1.0 line)
>>svn co http://myserver/repos/prj/branches/1.0 .
>>...do the patch...
>>svn commit....
>>svn copy http://myserver/repos/prj/branches/1.0 http://myserver/repos/prj/tags/1.0.1
>>
>>
>>The main stream is always prj/trunk that now "starts" from the work done for 2.0.
>>
>>Thanks to everyone for all the suggestions,
>>Guido.
>>
>>
>>
>>
>>>2)copy the trunk to branches/1.0 and then merge branches/2.0 into the
>>>trunk (and delete branches/2.0 until 2.0 is released).
>>>
>>>Scott
>>>
>>>
>>>---------------------------------------------------------------------
>>>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
>
>
>
>
Tnx for the info...
It seems that there is not just one best practice. Most important thing
is to think it through en check if it works well in a specific environment.
If anyone else has some other insights on repo management, I'll be very
happy to hear about them.
Regards,
Jeroen Leenarts
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org