Issues using mq on large projects

[Alexis S. L. Carvalho]

Thus spake L. David Baron:
> 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.)

The standard answer to work around these issues is to use something like
ccache.

I could also see some helper scripts to save the mtime and hash of the
files touched by the patches, and restore the mtime later if the hash
matches the current 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).

True - you probably know about
http://www.selenic.com/mercurial/wiki/index.cgi/MqMerge which I guess
qualifies as difficult.

Having this automated would be nice.

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

Putting something like this in ~/.hgrc should fix this:

[defaults]
qrefresh = --git

This tells qrefresh to always use the git extended patch format, which
can handle executable mode changes, copies, renames and binary files.
Even though the patch file in .hg/patches may not be understandable by
/usr/bin/patch , the output of hg diff of hg export after applying the
patch should be fine.

Alexis