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