Issues using mq on large projects

L. David Baron dbaron at dbaron.org
Sun Mar 4 19:27:19 UTC 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.

-David

-- 
L. David Baron                                <URL: http://dbaron.org/ >
           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: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20070304/e51eba83/attachment-0001.asc>


More information about the Mercurial mailing list