Some initial impressions of phases
Jason Harris
jason at jasonfharris.com
Tue Jan 24 14:40:49 CST 2012
On Jan 24, 2012, at 8:30 PM, Matt Mackall wrote:
> On Tue, 2012-01-24 at 19:25 +0100, Jason Harris wrote:
>> On Jan 24, 2012, at 5:47 PM, Matt Mackall wrote:
>>
>>> On Tue, 2012-01-24 at 09:14 +0100, Jason Harris wrote:
>>>> On Jan 23, 2012, at 11:03 PM, Matt Mackall wrote:
>>>>
>>>>>> Point 3.
>>>>>>
>>>>>> The following is a major point and not just some nit pick.
>>>>>>
>>>>>> Which other core mercurial command *both* changes state, and reports it using
>>>>>> the same command?
>>>>>
>>>>> Several (such as branch and bookmark). And if I had it to do over again,
>>>>> several more.
>>>>
>>>> (Were you thinking of push and pull where you would have had an option like
>>>> --show to instead get the effect of outgoing and incoming? I for one am glad
>>>> that there is no --show option. Iw Very rarely do people push when they wanted
>>>> to do outgoing but if there was the option --show I bet lots of people would
>>>> occasionally miss that option and inadvertently push stuff.)
>>>
>>> No, I'm thinking of tag/tags.
>>>
>>>> I had forgotten about these since I normally use these through my GUI, however
>>>> even so at least with branch and bookmark one changing the primary argument of
>>>> the command. Eg
>>>>
>>>> "hg bookmark" vs "hg bookmark <name>" "hg branch" vs 'hg branch <name>"
>>>>
>>>> However the command to change phase is an option.
>>>>
>>>> "hg phase 970:tip" vs "hg phase --draft --force 970:tip"
>>>>
>>>> Actually looking at this command it's the actual revision which is the target of
>>>> the command, so "hg phase --draft --force --rev 970:tip" can be equivalently
>>>> stated as "hg phase --draft --force 970:tip"
>>>>
>>>> Does this happen with other commands?
>>>
>>> Several, actually. Consider update and export. It's there so that people
>>> who get in the habit of using -r don't get bitten when a command expects
>>> a rev without a -r.
>>
>> Well update can't take a range
>
> Incorrect. Just about all commands now take revsets and thus now
> implicitly support ranges.
Incorrect. What does it mean to update to a range of revsets? Maybe it means the end
of the range, but fundamentally update only updates to a single revision, ie update cannot
update to some superposition of revision states :)
>> , and I have always found export a tiny bit odd
>> that the file spec is -o. It reverses what bundle does, and arguably if I had
>> been around at the time I would have argued that we should have more modeled the
>> signature of export on the signature of bundle. etc. But anyway that's water
>> under the bridge.
>>
>> What isn't yet water under the bridge is the signature of phase.
>>
>> Ie which of the following is more consistent with the other commands
>> which take or operator on ranges:
>>
>> (a) hg phase --force --draft 970:tip
>> or
>> (b) hg phase --force --rev 970:tip draft
>
> Both are valid, and both are documented as being valid:
You mean in 'hg help phase' ? Not as far as I am reading the documentation.
> hg phase [-p|-d|-s] [-f] [-r] REV...
In any case:
[salt:.../MacHgClone26] MacHgClone26 1014(1014) $ rhg phase --force --rev 1000:tip draft
hg: parse error: can't use draft here
[salt:.../MacHgClone26] MacHgClone26 1014(1014) $ rhg phase --force --draft 1000:tip
[salt:.../MacHgClone26] MacHgClone26 1014(1014) $
In any case it appears that form (b) is not accepted.
But from what you say it's just an implementation bug that form (b) is not working.
>>>> So currently people working all within the one tree will be ok. People working
>>>> with clones won't have phase generally doing the right thing(™).
>>>
>>> The price of admission to this conversation is:
>>>
>>> http://mercurial.markmail.org/search/?q=local%20clone%20phase
>>>
>>>>>> Point 8.
>>>>>>
>>>>>> No relevant information is reported upon success:
>>>>>
>>>>> Welcome to Mercurial. Use -v.
>>>>
>>>> Hmmm... Aside from the snide response, I had felt through usage that normally
>>>> mercurial reports something on success. Maybe it's just I use those commands
>>>> more often that report something.
>>>>
>>>> In a quick survey of the commands, I noticed the following commands don't report
>>>> anything bookmark, tag, add, forget. In fact bookmark doesn't even report
>>>> anything even with -v, whereas tag, add, and forget report something with -v.
>>>>
>>>> However, Commit, Clone, push, pull, rollback, update, branch, and revert do
>>>> report information. (Obviously commands like Incoming, outgoing, log, status,
>>>> etc report information.)
>>>
>>> You are wrong about commit and revert. Lots of commands are silent on
>>> success, it's the default stance.
>>
>> I thought I had tested commit. Maybe I some option set or something... But in any case
>> revert seems to print a message upon reverting stuff:
>>
>> Last login: Tue Jan 24 16:32:49 on ttys000
>> [salt:~] $ mkdir hgtest
>> [salt:~] $ cd hgtest
>> [salt:~/hgtest] $ echo a > a
>> [salt:~/hgtest] $ hg init
>> [salt:~/hgtest] hgtest $ hg commit -A -m "initial commit"
>> adding a
>> [salt:~/hgtest] hgtest 0(0) $ echo b >>a
>> [salt:~/hgtest] hgtest 0(0) $ hg commit -A -m "second commit"
>> [salt:~/hgtest] hgtest 1(1) $ hg revert --all --rev 0
>> reverting a
>> [salt:~/hgtest] hgtest 1(1) $ hg version
>> Mercurial Distributed SCM (version 2.0.2+20120104)
>> ...
>>
>> So it seems like revert does report stuff.
>
> It reports non-explicitly mentioned filenames, just like add, addremove,
> and commit -A.
Just my point. In some cases you get messages. When you are updating phase and
it does something a little dangerous like moving the phase boundary in the
"wrong" direction then a one line message would be nice to receive...
Cheers,
Jas
More information about the Mercurial-devel
mailing list