Re: Branching/Merging Best Practices

Sorry, I accidentally sent this directly to Nick. Hopefully this time
it will go to the entire list.

==================================

Thanks, Nick. That makes a lot of sense and is the exact opposite of
how I was thinking of things. I'm glad I asked. If I understand
correctly, then at any given time there may be development actively
ongoing against the trunk and one or more branches. For some reason I
was thinking that the trunk was sacred. I have no idea why.

Let me ask one follow up question to see how you'd handle the scenario
I'm about to face...once I import my current stable version and create
a branch for that version my trunk will look exactly the same as that
branch. For the next version, though, the code base will be entirely
reorganized - new folder structure, pathing, etc. Should I do that
work directly on the trunk or is that something so massive that it's
better handled on a branch? How are major overhauls like this handled
in other shops?

Thanks again for you thoughts.

On 7/12/06, Nick Thompson <nickthompson@agere.com> wrote:
> 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
>
>

-- 
Rob Wilkerson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org