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

[Dan Villiom Podlaski Christiansen]

On 08/07/2009, at 00.30, Michael Sommerville wrote:

>
> 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.

Not really; you earlier acknowledged that there were good arguments  
for not making MQ the second command installed by Mercurial. If it  
isn't installed by default — as MQ currently is — it isn't available  
to all users, and thus doesn't fully address 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.

I agree. But adding that involves much more digging into the innards  
of MQ and Mercurial than I did for this patch :)

>>> 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.

But if the ‘mq’ script isn't available to everyone that ‘qcommit’ and  
‘qclone’ are available to now, it can't provide a functional  
replacement of MQ. Thus, deprecating — and eventually removing — those  
commands would lead to Mercurial being less capable to some users.

> However, IMHO, the suggested '-Q' option is a far more elegant  
> solution from a users perspective.

I couldn't have said it any better myself ;)

On a related note, I've made the wrapper use a whitelist rather than a  
blacklist, and implemented basic deprecation and hiding for ‘qcommit’.  
I'll send the patches in a follow-up to this mail.

(The other patch I sent fixed ‘hg outgoing -Q’.)

--

Dan Villiom Podlaski Christiansen
danchr at gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1943 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial-devel/attachments/20090710/f0188de3/attachment.bin