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
signature.asc
Description: PGP signature
-- ubuntu-distributed-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
