Branching best practices (In reply to: Adopting a branch as trunk)

[Jeroen Leenarts <le...@tiscali.nl>]

Ron Bieber wrote:

> On Thu, 2004-12-02 at 06:52, Guido Anzuoni wrote:
>
>>/Hi,
>>I think it works, but just to be sure....
>>
>>I have a project with the following layout
>>
>>prj/trunk
>>prj/tags
>>prj/branches/2.0
>>
>>In prj/trunk there is the "1.0" line of development.
>>In prj/branches/2.0 there is the "2.0" line of development.
>>
>>At some point in time I what to let the trunk adopt the 2.0 line of 
>>development (i.e stop development on prj/branches/2.0 and continue on 
>>prj/trunk).
>>
>>Is it safe to do the following ?
>>svn delete //_http://myserver/repos/prj/trunk_
>>svn copy _http://myserver/repos/prj/branches/2.0_
>>_http://myserver/repos/prj/trunk_
>>/
>>
> For our projects, we branch the trunk to a "1.0" branch and 
> subsequently merge the 2.0 version into the trunk.   From this point, 
> the people working on 1.0 can svn switch to the 1.0 branch and resume 
> their work where they left off, while the 2.0 people can check out the 
> trunk.
>
> This way, if the 1.0 release needs bug fixing, you can do the fixing 
> and merge back to the trunk to reflect the change.
>
>>/What happens if I have a wc in sync with the old prj/trunk and I issue a
>>svn update .
>>after this "switch" at repos level ?
>>
>>I have made a little test on a sample repository an it seems to be OK.
>>
>>Is there anyone who has adopted this practice ?
>>Is there anyone who has experienced pb with this practice ?
>>
>>TIA
>>
>>Guido.
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>>For additional commands, e-mail: users-help@subversion.tigris.org
>>
>>/
>>
Just being courious...

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?

The setup I described *seems to me* to be the "prefered way" of dealing 
with your branches when taking the to the description about repo setup 
and merging in "The Book" into account.

Regards,
Jeroen Leenarts


---------------------------------------------------------------------
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)

[Scott Palmer <sc...@2connected.org>]

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.

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.

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