Re: Branching/Merging Best Practices

On Tuesday 11 July 2006 19:18, Rob Wilkerson wrote:
> I'm working on establishing a process for using Subversion once we
> have completed a conversion from VSS and I'd like to get some
> advice on how/when to merge back into the trunk. I'm not going to
> carry any legacy history over from VSS. Instead, I'm going to
> leave it where it is and start fresh with Subversion using the most
> recently released code base for the product.
>
> From the point of view of an inexperience Subversion user, the most
> intuitive process seems to be this:
>
> 1. import latest code into the trunk of the product repository
> 2. create a branch to begin developing the next version
> 3. create another branch to provide a maintenance release
>
> So now I have 2 branches from the same trunk and I have several
> questions:
>
> 1. After development of the maintenance release has been completed
> and tested, is it a good practice (I'm assuming it is) to merge
> that "fixed" code into the branch created for the next version of
> the product?
> 2. Since it is a maintenance release of the code that makes up the
> trunk, should I merge that maintenance release code back into the
> trunk when it's released?
> 3. The product, like many others, has major, minor and maintenance
> releases. Should any or all of these be merged back into the trunk
> or should branches be left as branches? If they should be merged
> back into the trunk then when is this usually done?
>
> I guess what I'm trying to figure out is the best workflow to use
> in the development lifecycle of a product. Any guidance would be
> much appreciated. High level process flow suggestions would help
> me tremendously.

The usual flow of things is to have your main development on trunk and
to branch out for release and subsequent maintenance of the release.
(You might also use branches for big changes that might break the
code after a commit, but where a commit is non the less required for
some reason - sharing, milestone capture, module testing. These
"feature branches" would be merged back to the trunk when the feature
is complete.)

Applying this to your situation, you would import your original code
release into trunk and immediately create a branch for maintaining
that release. Development of the next version would then proceed on
trunk, until you are ready for the next release. At that point you
would branch a new release/maintenance branch. Development for the
subsequent version then proceeds on trunk again.

Merges are simply made on an as required basis. Your process will need
to include a review board to decide if each fix applied to a
maintenance branch should also be applied to trunk, in which case it
is merged or manually duplicated - a maintenance fix may not be able
to use an optimal solution for example. Same for fixes on the trunk,
do they need to be back ported to any maintenance branches? Again,
merges may do the job here, but since this is a back port, the fix
may have to take a different form.

Anyway, that's more or less what we do, but I don't think I could
claim it as Original Work. :-)

Good luck.

-- 
> Nick Thompson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org