Issues using mq on large projects
dholth at fastmail.fm
Sun Mar 4 14:30:34 CST 2007
-----BEGIN PGP SIGNED MESSAGE-----
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.
For problem #4, put
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
- - Daniel Holth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Mercurial