Managing multiple maintenance branches

[Michael B. Trausch]

On Wed, 08 Apr 2009 10:16:11 +0100
Russel Winder <russel.winder at concertant.com> wrote:

> Currently I have a shared repository with checkouts of Subversion
> branches, Trunk, 1.6.x and 1.5.x.  In the same shared repository I
> have branches off these Development, 1.6.x_Development,
> 1.5.x_Development. All changed go through the development branch and
> when released are pulled into the mirror checkouts.

What I do is one of two things:

 * For my public project, I keep branches on LP and just have in my
   local shared repo the branches I am working on.  As time moves
   forward, if I need to backport fixes, I'll just branch from LP the
   release that needs fixed, handle that fix, and push back up.

 * For my non-public projects, I either handle the workflow like I do
   with LP, though substitute another bzr server in its place, or, I
   have a local shared repository without working trees, and have a
   working area where I have a shared repo with working trees.

In the end, the overall point is that I only have working trees for
things I am working on ATM; for everything else, I have a shared repo
without working trees that is a reference point.

As an example, I have one repo for a client where they have a bzr
server with a shared repository.  The shared repo looks like this:

  SHARED_REPO/
  + trunk/
  + v1-release/
  + v2/
  + v2/release
  + v2/{misc-topic-branches}
  + v2/2.1
  + v2/2.2

This repository on the server does not contain any working trees, and
it is viewable from a Loggerhead instance.  It is the central reference
point for any branches which need work.

The preferred workflow is for people to branch on the current release
(e.g., v2/2.2), creating in effect a local topic branch, working on
that, and merging it back up to v2/2.2 for others to get.  If the topic
branch is expected to last longer than a little while, or has
significant changes, it gets pushed up to the v2/ area with a topic
branch name and it can be looked at and reviewed, and at some point
will be merged with, say, v2/2.2.

I do something similar with my local projects.  I have a shared
repository for each project I work on in /srv/bzr on my server at home
(on my LAN).  It contains a series of directories for each project that
look like the above shared repository, and I interface with it the same
way.

Usually, per each project, I only have one or two working trees of
source at one time---just the ones that I am working on, ATM.  If I am
not working on it, there's no reason for me to have local changes (that
is, in $HOME) since I can just push those to a topic branch on the
server (Launchpad, my client's server, or the server on my LAN) and
remove the working tree and revisit it later.  In practice, I don't
_always_ do this, but I do pretty often, because it effectively gives
me separate namespaces to work with and I can more quickly place my
focus on things that I am doing.  If I need to do a merge, I'll "bzr
branch" the merge destination, do the merge, push it back up, and then
remove the local branches involved if I am done working with them.

	HTH,
	Mike