Issues using mq on large projects

Daniel Holth dholth at fastmail.fm
Sun Mar 4 14:30:34 CST 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

L. David Baron wrote:
> 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
David,

For problem #4, put

[diff]
git=1

in your .hgrc (Mercurial.ini on Windows). This causes Mercurial to use
the git binary patch format. It adds binary file support and can store
renames. Only downside is that /usr/bin/patch doesn't understand the
new features.

- - Daniel Holth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF6yxpVh4W2pVfoMsRAuwyAJwIG6Sk/sGvB4Bx9NTD4P9agOAvrgCffMSd
/IUhHtgsQRWqdzXdcBEZdzI=
=FqbS
-----END PGP SIGNATURE-----



More information about the Mercurial mailing list