Battle royale: bzr vs. quilt

[Barry Warsaw]

On Dec 07, 2010, at 03:17 PM, Barry Warsaw wrote:

>Agreed.  I am going to play with the looms idea and Scott's suggestion to see
>if I can clean up the workflow a bit.  I will definitely update the UDD wiki
>page, and the information you've provided has been very helpful!  I clearly
>had no idea what I was talking about when I first wrote that page. :)

A quick follow up.  It is possible to use looms to help keep things clean, at
least until you start updating patches.  For example:

    bzr branch graphviz myfix
    cd myfix
    bzr loomify --base trunk
    bzr create-thread sourcefix
    <hack, commit>
    bzr create-thread quiltfix
    bzr diff -rthread:trunk..thread:sourcefix | quilt import -p0 -P myfix
    bzr add debian/patches/myfix
    bzr commit
    quilt push
    quilt pop

Why the last push/pop?  The push gets the import changes into a quilt patch,
but also leaves the tree modified.  The pop undoes the tree change (which is
available in the sourcefix thread) but leaves the quilt change available.  A
`bzr commit` at this point gives you a thread with just the changes to
debian/.

The problem comes in when you want to modify the patch, e.g.:

    bzr down-thread
    <hack, commit>
    
This does *not* work well:

    bzr up-thread

Because of the `quilt pop` above, your myfix patch is not at the quilt top, so
push it.

    quilt push

Now myfix is at the top, and your tree reflects its changes too.  This gives
you the updated patch you want:

    bzr diff -rthread:trunk..thread:sourcefix

but this can cause patch failures and rejections:

    bzr diff -rthread:trunk..thread:sourcefix | quilt fold -p0

In this case, I think it's better to throw away your quiltfix thread and
essentially regenerate it:

    bzr up-thread
    bzr revert
    bzr combine-thread --force
    bzr create-thread quiltfix
    bzr diff -rthread:trunk..thread:sourcefix | quilt import -p0 -P myfix
    bzr add debian/patches/myfix
    bzr commit

At this point, `bzr diff -rthread:` gives you just the changes to debian/.
This ought to make it very easy to generate a diff for Debian, or anybody else
wanting to review a diff instead of an mp.

If you do want to close the loop using an mp though, you can do it, but it's a
little bit ugly.  A bzr push to Launchpad of a loomified branch works, but the
branch details and resulting merge proposal will look like an mp of the top
thread into the trunk.  Launchpad really has no way to deal with looms from
the ui.  So you'll see both the in-tree change and the quilt change in the
merge proposal.

Now, what happens when a sponsor wants to apply and upload the change?  One
thing you *don't* want to do is:

    bzr branch ubuntu:graphviz
    cd graphviz
    bzr merge lp:~barry/ubuntu/natty/graphviz/udd

Badness (in the form of infinite 'maximum recursion depth' exception) ensues.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-distributed-devel/attachments/20101207/347edb92/attachment.pgp