Battle royale: bzr vs. quilt

[Barry Warsaw]

Here's something I hit while working on a graphviz ftbfs (bug 683182).  It
illustrates a problem when using bzr to work on a quilt 3.0 package.  Maybe
it's a bug, or maybe it's a misunderstanding on my part.  If the former, I'll
be happy to file a bug.  If the latter, please enlighten!  In either case I do
not think this wiki page gives helpful or usable instructions right now:

https://wiki.ubuntu.com/DistributedDevelopment/Documentation/PatchSystem

(which is my fault; I wrote the page and ISLAGIATT[*] :)

Steps to reproduce:

    bzr init-repo graphviz
    cd graphviz
    bzr branch ubuntu:graphviz (or lp:ubuntu/graphviz)
    bzr branch graphviz udd
    cd udd

At this point notice that the .pc directory is under version control.  We've
talked about this before, but it is currently deliberate that the package
importer includes the .pc directory for quilt in bzr.

    quilt push -a

I would have expected at this point that a `bzr stat` would show lots of
modifications to the source tree, but in fact, it shows nothing.  quilt
definitely reports that all the patches in the series have been applied, but
if so, where are they?

    quilt pop -a

This is supposed to un-apply all the patches so that "the source returns to
the downloaded condition" [http://wiki.debian.org/UsingQuilt].  I would expect
at this point that a `bzr stat` would show no changes, but in fact it shows
tons of removes from the .pc directory and modifications to all the source
tree files.  If I look at `bzr diff`, it does indeed seem like the patches
have been un-applied.

So it seems like the source branch already has the effects of `quilt push -a`
applied.

Maybe that's a good thing, but I want to be sure it's deliberate.  It could be
good because from a developer's standpoint, I can just dig in and start
hacking the code to get a diff from the fully pushed state to the changes I
want to make.  But the workflow is a little mysterious to me.  The best I've
come up with is:

    bzr branch graphviz udd
    cd udd
    <hack>
    bzr diff | quilt import -p0 -P mypatch /dev/stdin
    quilt push
    bzr add debian/patches/mypatch
    ???

So now what do I do?  I've got the change sitting in a quilt patch and in my
tree.  I clearly can't submit a merge proposal in this state.

A `quilt pop -a` right now is definitely *not* the right thing to do because
of the above described problem.  I've also got a change to .pc/applied-patches
(along with several .pc unknown changes).

The best I've come up with is:

    quilt pop
    bzr revert <manually, all files I modified during the hackfest>

Now I'm left with a tree that contains my change embodied just in a quilt
patch, which is pretty much where I want to be.  Of course the manual revert
(you can't use auto revert because you'd lose the changes to debian/patches/)
is a PITA but it's possible that putting looms in the mix would make that
easier (haven't yet tried, but seems plausible).

Does the above make sense?  Any clarifications on what's going on under the
hood?  Any suggestions to make things with udd and quilt go more smoothly?

If this is the best we can do, then the next thing to figure out is whether
looms can help with the bzr revert, or whether an enhancement to bzr revert
would be useful (e.g. `bzr revert --not debian` would revert everything except
the debian directory).

Cheers,
-Barry

[*] it seemed like a good idea at the time
-------------- 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/5101a3b6/attachment.pgp