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
Received on Fri Dec 3 13:48:45 2004