Issues using mq on large projects

L. David Baron dbaron at
Sun Mar 4 13:27:19 CST 2007

I've been using mercurial and mq for my Mozilla development work for the
past two months (and manually using one of my repositories as a gateway
to/from our CVS).  I realized pretty quickly that mq doesn't really meet
my needs, but I've been thinking a little more slowly about what I want
to replace it.

The things I don't like about mq are the following:

 (1) I can't edit a non-topmost patch without unapplying and applying
     all the patches above it, forcing a much larger recompile than
     really necessary.

 (2) I can't push a patch without applying and unapplying all the
     patches above *and below* it, forcing a potentially large recompile
     (for the next time I rebuild) when no recompilation is necessary.

These are particularly bad for me because rebuilding after applying or
unapplying some of my patches is quite expensive; never less than 30
seconds and frequently 15-30 minutes, or even 60 for a tree-wide
rebuild.  (The past week I've had a bunch of patches in my queue that
require a tree-wide rebuild, and it's been quite painful.  For example,
I just pulled the commits for the past few days, which required merging
a patch that was lower down in my queue to match changes elsewhere in
the file, but I didn't see the compilation error until a good way
through the build.  To fix this and update the patches in my queue, I
needed to make changes that forced the build to start over from scratch,
even though I was only changing one file.)

It also bothers me that:

 (3) Getting the benefits of easy 3-way merging is difficult (since I
     lose one of the main advantages of switching to a modern version
     control system).

 (4) Binary files in patches end up getting dropped (as a consequence of
     the patch storage mechanism).

I'd like to either see mq evolve to meet my needs or have something else
that does.

I've been thinking a bit about the latter, although I'm not sure whether
I'd have time to take on a project of that size.  (I certainly wouldn't
do so unless Mozilla decides on mercurial as its new VCS, which is not
yet chosen.)  I plan to follow up later with some thoughts on how I'd
like to see such a system work (which I'm still in the middle of
writing), but I'm interested if others share these concerns about mq and
if there's any existing work to alleviate them.


L. David Baron                                <URL: >
           Technical Lead, Layout & CSS, Mozilla Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :

More information about the Mercurial mailing list