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