What do you do with MQ?

[Tony Mechelynck]

On 06/12/11 15:42, Arne Babenhauserheide wrote:
> Hi,
>
> Mercurial Queues offer extremely powerful options for working with
> unfinished changes.
>
> It’s general usecase is clear: manage a queue of patches against a
> given repository. But that is so vague that it does not say very much
> and it also does not describe everything you can do with mq. So it
> interests me, what you do with MQ in terms of actual actions.
>
> To show what I mean instead of just telling, these are mq actions
> which strike me as directly useful even when I don’t explicitely track
> patches:
>
>
> * amend the latest commit:
>    hg qimport -r tip ; hg qrefresh; hg qfinish -a
>
> * fold two changesets:
>    hg qimport -r REV -r REV; hg qpop -a ; hg qfold ; hg qpush ; hg qfinish -a
>
> * do many test commits and fold them into one when finished:
>    hg qnew -m "change" 1; hg qnew -m "fix" 2; hg qpop 2 ; hg qfold 2 ; hg qfinish -a
>
> * refactor commits to have atomic changes (one step per changeset):
>    (I failed to find an easy way here. What I’d need: hg qsplit: like
>    qrecord, but takes the changes out of one patch and puts them into a
>    new one. Then I could just qfold all related patches and qsplit them
>    into atomic changesets)
>
>
> Which mq actions do you use? (including those for tracking patches)
>
> Best wishes,
> Arne
>
> PS: I ask because I think that mq is mostly opaque to new users (it
> was for me) even though it might fill some basic usecases as soon as
> users want to change local history. For example to refactor patches
> for inclusion in Mercurial.
>
> PPS: I think this information should be quite useful for Liquid, too.
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial

Config settings in hgrc are assumed to be set the way you want them. I 
use (among others)

[ui]
verbose=true
[diff]
git=true
unified=8

but YMMV. I assume that patches are applied to the tip of the repo; I 
haven't yet met bit-rot, I'll handle it (probably at step B3 below) when 
I get to it.

A. to create a new patch
1. (optional) hg qqueue -c queuename
2. hg pull -u (or "hg fetch" if enabled)
3. make some changes in the working directory tree
4. hg qnew -m 'commit message' patchname

B. to make some changes in a patch (assuming it's at top of its queue)
1. (if done previously) hg qqueue queuename
2. hg pull -u (or "hg fetch" if enabled)
3. hg qpop
4. make some more changes
5. hg qrefresh
6. hg qpush

C. to send a patch to whoever has the privileges to push it
1. make sure the patch has been qnew'ed, or qrefresh'ed and qpush'ed
2. The patch is found in its queue (by default .hg/patches, or 
.hg/queuename if you specified one). Attach it to a Bugzilla (or 
similar) bug report, to an email, or whatever.

My main device for tracking patches is to name them according to the 
corresponding Bugzilla (or other bug tracker) "bug number". Commit 
message includes the bug number, bug title, and is updated at push time 
with the names of whoever reviewed (and if applicable superreviewed, 
authorized, etc.) the patch. Commit "author" name is the patch author, 
not necessarily the name of whoever did the actual push on his behalf.

Notes:
1. Any changesets created in the public repo remain there forever, in 
conformity with the Mercurial "frozen history" dogma. Anything else 
would wreak havoc with the local clones of anyone who "pulled" in the 
meantime. If a patch is found to be bad after being pushed to the public 
repo, it may be backed out (by a new changeset) then later a corrected 
patch may be pushed (creating a third changeset).
2. Patches are kept "not applied" on the local clone except when working 
on them (at step A3 or B4), to create no unnecessary problems with e.g. 
a cron-daily job pulling the latest changes in the middle of the night.


Best regards,
Tony.
-- 
hundred-and-one symptoms of being an internet addict:
235. You start naming your kids Fortran, COBOL, Algol, and Pascal.