[PATCH 0 of 3] Add option for operating on queue repository

[Michael Sommerville]

On 7 Jul 2009, at 20:13, Greg Ward wrote:

> On Tue, Jul 7, 2009 at 11:49 AM, Dan Villiom Podlaski
> Christiansen<danchr at gmail.com> wrote:
>> Versioning a patch queue doesn't have to be any more advanced,  
>> difficult or complicated
>> than just dealing with the patch queue itself. I'd say the current  
>> difficulty is caused by the
>> limited interface to the queue repository.
>
> Right.  And either -Q or '/usr/bin/mq' addresses that difficulty.

I'm not sure that I  entirely agree.  In my experience, trying to make  
sense of diffs of diffs is hard.  It would be really nice to have a  
means of producing the resultant diff in the base repo between  
arbitrary revisions of the patch repo, and have this functionality  
replace what 'mq diff' currently does.    From the pbranch page, it  
would seem that such functionality is a part of that extension already.

>> In my opinion, an
>> option for dealing with the queue repository has many advantages:
>>
>> 1) Generally, options are easily discovered and simple to type and  
>> work with.
>> 2) The option consistent: -Q/--queue has the same meaning for every  
>> command recognising it.
>
> Both true.  #1 in particular argues for -Q over 'mq'.
>
>> 3) The option could lead to less clutter, by either hiding,  
>> deprecating or removing some of the
>> commands exposed by MQ. The obvious example of this is qcommit, but  
>> it could also apply
>> to qinit and qclone.
>
> Factoring out an 'mq' command has the same benefit: it would
> theoretically let us deprecate/eliminate qcommit and qclone.  So -Q
> doesn't really have any benefit there relative to 'mq'.  They both
> beat the status quo.

Personally, I like the like 'mq' approach too, but only because it is  
quicker to type.  I hacked together such a wrapper script  a while ago  
for use on windows and it works well enough for me.  However, IMHO,  
the suggested '-Q' option is a far more elegant solution from a users  
perspective.

-Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mq
Type: application/octet-stream
Size: 837 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial-devel/attachments/20090707/acfc59c9/attachment.obj 
-------------- next part --------------