Using feature branches to manage packaging with bzr (was: Future of REVU and Debian Mentors)
robertc at robertcollins.net
Tue Aug 7 04:23:02 BST 2007
On Mon, 2007-08-06 at 22:56 -0400, Michael Olson wrote:
> Reinhard Tartler <siretart at ubuntu.com>
> > "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.
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20070807/78a929c0/attachment.pgp
More information about the Ubuntu-motu