Using feature branches to manage packaging with bzr

[Michael Olson]

Robert Collins <robertc at robertcollins.net> writes:

> On Mon, 2007-08-06 at 22:56 -0400, Michael Olson wrote:
>> Reinhard Tartler <siretart at ubuntu.com> writes:
>> > 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.

Agreed.

>> 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.

These both still require that separate working trees lie around on the
disk for each branch somewhere, right?  It doesn't seem like bzr is
capable of keeping track of all branch information in a single .bzr
directory like git does with its .git directory.  That's a big lose for
this particular situation, in my opinion.

>>  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'.

True.  It's not so much the disk space that I'm worried about as much as
having to define some sort of directory structure to hold all of these
branches.

>>  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.

Hmm.  I didn't realize there would be one "merged" branch that contains
all of the work done on the active feature branches.  I was thinking of
some sort of "series" file that would contain a listing of branch names
and the order in which they should be applied by the patch/unpatch
targets in debian/rules.  I would think that for a "merged" branch,
there would be the temptation for contributors to just check changes
directly in to it without first going through a feature branch, which
would break the ability to get a diff that contains just the work done
on a single feature.

-- 
       Michael Olson -- FSF Associate Member #652     |
 http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net  |  /` |\ | | |
            Sysadmin -- Hobbies: Lisp, GP2X, HCoop    | |_] | \| |_|
Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20070807/73415a36/attachment.pgp