I’ve spent most of the last 2.5 days merging code that lives in mercurial patch queues. It’s been an interesting (and frustrating) experience, but I’ve learned a lot, so I put together this tutorial on maintaining\/merging\/updating a mercurial patch queue.<\/p>\n
The XPCOMGC patch queue was actually 60+ patches long, but for example purposes let’s simplify to 7. What makes it tricky is that patches “after” the automated rewrites often won’t apply cleanly to the tree before the automatic rewrite. This means that moving patches from “after an automatic rewrite” to “before an automatic rewrite” requires a merge algorithm. Imagine a patch series like this:<\/p>\n
manual-fixbugA\r\nmanual-fixbugB\r\nautomatic-rewrite-comptrs\r\nautomatic-rewrite-classhierarchy\r\nautomatic-rewrite-addrefs\r\nmanual-fixbugA-patch2\r\nmanual-fixbugC<\/pre>\nYou may be wondering about “manual-fixbugA-patch2″… why didn’t I just go back to manual-fixbugA and change it? This is because, once you’ve applied an automatic rewrite, popping\/editing\/pushing requires not only a complete tree rebuild (20 minutes), but also rebuilding the automated patches (hours). Instead, I create a “patch2” (and sometimes a “patch3” and “patch4”) and later fold the patches together.<\/p>\n
Reordering a patch queue<\/h3>\n
I want to clean up this patch queue and update the “base tree” on which I’m applying patches. To do this, I’m first going to move all the “manual” patches before the automatic rewrites. Some of the patches may not apply cleanly in their new positions, so we prepare for merging. 64<\/p>\n
$ hg qpush -a; # Push all patches\r\n$ hg qsave -e -c; # Save the patch queue state... this allows for merging later\r\n$ hg update -C qparent; # Move the working directory back to a completely unpatched state<\/pre>\nNow we edit the .hg\/patches\/series<\/tt> file, removing the automatic rewrites. Instead of attempting to merge the automatic rewrites, we will simply regenerate them later.<\/p>\n
manual-fixbugA\r\nmanual-fixbugB\r\nmanual-fixbugA-patch2\r\nmanual-fixbugC<\/pre>\nNow we push the patches back on: if a patch doesn’t apply cleanly, use a three-way merge algorithm based on the saved patch queue state:<\/p>\n
hg qpush -m; # applies manual-fixbugA\r\nhg qpush -m; # applies manual-fixbugB\r\nhg qpush -m; # applies manual-fixbugA-patch2 with interactive merging\r\nhg qpush -m; # applies manual-fixbugC with interactive merging<\/pre>\nNow, we want to merge the changes from “manual-fixbugA-patch2” into “manual-fixbugA”<\/p>\n
hg qgoto manual-fixbugA;\r\nhg qfold manual-fixbugA-patch2;<\/pre>\nNow we have a clean patch queue which is ready for updating to a new “base”:<\/p>\n
hg qpush -a; # Push all patches in preparation for our second merge\r\nhg qsave -e -c; # Save the patch queue state (again)\r\nhg pull http:\/\/hg.mozilla.org\/actionmonkey; # Pull new changesets from actionmonkey\r\nhg up tip; # Update the working directory to the unpatched actionmonkey tip\r\nhg qpush -m; # merge the patches one by one, with merging if necessary<\/pre>\nIn the case of XPCOMGC, “new-base” merges are difficult primarily because of the cycle collector. Cycle-collection is still be actively developed on trunk, with major changes to the xpconnect mark\/trace algorithms as well as changes to timing. One of the earliest patches in the XPCOMGC queue removes cycle-collector entirely (when we have a garbage collector for XPCOM objects a cycle collector is no longer needed). Merge conflicts are common not only in the patch which removes the cycle collector, but in subsequent patches which touch xpconnect.<\/p>\n
I’ve learned that merging goes much better if every patch in the patch queue produces a building tree. To test whether a merge was performed correctly (or discover which patch was merged incorrectly), simply build the tree at each patch state.<\/p>\n
Conclusion<\/h3>\n
Mercurial patch queues make it possible to merge-update a series of patches against a moving base, which is very cool. But they don’t remove the actual hard work of merging changes that conflict.<\/p>\n","protected":false},"excerpt":{"rendered":"
I’ve spent most of the last 2.5 days merging code that lives in mercurial patch queues. It’s been an interesting (and frustrating) experience, but I’ve learned a lot, so I put together this tutorial on maintaining\/merging\/updating a mercurial patch queue. The XPCOMGC patch queue The XPCOMGC patch queue was actually 60+ patches long, but for […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[41,56,62,63],"class_list":["post-186","post","type-post","status-publish","format-standard","hentry","category-mozilla","tag-mercurial","tag-mozilla2","tag-mqueue","tag-xpcomgc"],"_links":{"self":[{"href":"http:\/\/benjamin.smedbergs.us\/blog\/wp-json\/wp\/v2\/posts\/186","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/benjamin.smedbergs.us\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/benjamin.smedbergs.us\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/benjamin.smedbergs.us\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/benjamin.smedbergs.us\/blog\/wp-json\/wp\/v2\/comments?post=186"}],"version-history":[{"count":0,"href":"http:\/\/benjamin.smedbergs.us\/blog\/wp-json\/wp\/v2\/posts\/186\/revisions"}],"wp:attachment":[{"href":"http:\/\/benjamin.smedbergs.us\/blog\/wp-json\/wp\/v2\/media?parent=186"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/benjamin.smedbergs.us\/blog\/wp-json\/wp\/v2\/categories?post=186"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/benjamin.smedbergs.us\/blog\/wp-json\/wp\/v2\/tags?post=186"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}