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
Received on Fri Dec 3 16:46:47 2004