Using feature branches to manage packaging with bzr (was: Future of REVU and Debian Mentors)

[Robert Collins]

On Mon, 2007-08-06 at 22:56 -0400, Michael Olson wrote:
> Reinhard Tartler <siretart at ubuntu.com>
> writes:
> 
> > "Emmet Hikory" <emmet.hikory at gmail.com>
> > writes:
> >
> >>     The reason I prefer a patch system is that it organises the
> >> patches by purpose, rather than historically.  With a VCS, it is very
> >> difficult to extract the specific set of changes required to
> >> implement a specific feature, especially when those changes may span
> >> several files, and have been updated several times during this
> >> history of the package to match upstream changes (often in
> >> combination with other updates).  Purpose-oriented patches are easier
> >> to review for adoption upstream, and easier to understand as an
> >> example to implement a similar feature in another package.
> >
> > This is adressed by the concept called 'feature branches', a concept
> > that Manoj Srivastava uses for his packages. A feature branch only
> > contains the changes that you would normally put in a dpatch. It can
> > be easily extracted and exported to a patch file. Furthermore, you can
> > track and merge changes with other developers.
> >
> > Together with the bzr-rebase plugin, I think the implementation of
> > feature branches with debian packages becomes more and more feasible
> > in bazaar.

I'm not sure rebase needs to be involved; rebasing discards revision ids
and harms collaboration.

> I'm intrigued by this idea.  Unless I'm mistaken, the main issues with
> using bzr for this is that bzr needs a separate working tree for each
> feature branch.  This causes the following problems.

bzr switch can switch between lightweight working trees. Fixing that for
heavyweight checkouts would be relatively easy; and pull --overwrite is
essentially the same thing for branches anyhow.

>  1. If working with a Launchpad-hosted repository, each branch has to be
>     registered with Launchpad before work can be done on it.

'bzr push' will create branches automatically on launchpad.

>  2. There are often a lot of individual patches in debian/patches --
>     making a feature branch for each patch seems slightly wasteful of
>     disk space.  This is not a huge concern since debian/ directories
>     are almost always small, but it would feel wasteful nonetheless,
>     compared to having just one working directory, like git offers.

On your local disk you can use a shared repository which shares the disk
storage between branches 'just like git'. 

>  4. A new contributor to the project would have to check out not just
>     the branch that has the debian/ directory, but also every single
>     feature branch, which could be a hassle.

I would be included to have the merged branch be what people checkout.
To edit a specific patch you then checkout the one feature branch you
want to edit, or make a new one, and then merge that in.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20070807/78a929c0/attachment.pgp