Some initial impressions of phases

Tue Jan 24 12:25:57 CST 2012

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

Ok a quick survey of the commands which operate on / or with revisions (or revision ranges)

(a) and revision-ranges: export, graft.
(a) and single-revisions: backout, update, bisect
(b) and revision-ranges: log, bundle, import, clone, diff, grep, incoming, outgoing, push, pull, status
(b) and single-revisions: annotate, archive, bookmarks, cat, identify, locate, manifest, merge, parents, revert, tag, tags

Thus I would state that the form of (b) is more common to mercurial, and
consequently for consistency we should change to it. It also just feels more
"mercurial" like from my experience.
(Also it makes the public, draft, or private / secret the main noun in
the command which feels like the correct thing to do...)

(I would still prefer 'hg setphase --rev 970:tip draft' since then setphase is
verb like... unlike phase which is a noun.)

>>>> Point 4.
>>>> 
>>>> How does one change the phase on commit? I thought this was meant to be an
>>>> option. Also there appears to be no mention of a phase option to any of clone,
>>>> push, pull, outgoing, incoming, etc. I had gathered that there was meant to be
>>>> something more on other commands?
>>>> 
>>>> Eg I had thought one might be able to do "hg commit --draft <files>"...
>>> 
>>> Deferred. Phases are designed to "just work" without you having to mess
>>> with them (or even being aware of them). The above is messing with them.
>>> Commits are draft by default, no messing needed.
>> 
>> It is nice that commits are draft by default. So the common workflow of being
>> able to commit stuff work with it, and then upon pushing note that it's public
>> and you have to do something to alter the history is almost there. The one thing
>> missing is still local clones, don't preserve the draft phase.
>> 
>> 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.

> 
>> If there is a definite pattern here I am not seeing it... It's a new command and
>> it's generally something "dangerous" so shouldn't something be reported here by
>> default. Too much feedback is of course spammy, but giving no feedback that
>> anything happened whatsoever for an operation which others are considering as
>> dangerous is not IMHO the best thing.
>> 
>>> 
>>>> Point 9.
>>>> 
>>>> The phase of the changeset when it differs from public is not reported by default.
>>>> [salt:.../MacHgClone14] MacHgClone14 972(972) $ rhg log --rev 968:tip
>>> 
>>> http://mercurial.selenic.com/wiki/CompatibilityRules#Commands (see what
>>> it says about log in particular).
>> 
>> Fair enough, (although almost anyone that parses this output will use a --template option...)
>> Still that's fine.
> 
> Realistically, for every person writing a fancy GUI client like you,
> there are 100 sysadmins who are parsing this output with grep and perl
> in the dumbest possible way for a cron job. This is the target audience
> of CompatibilityRules, not you.

Maybe. But more importantly as a way forward, what about the idea of
"hg log --style modern" which people can then set in their hgrc,
or maybe something else which "just does the right thing"?

Even if it's not the default having some simple and convenient way to get
log results with phases would be nice. (Of course if not then some thousands of
mercurial users world wide will start to investigate rolling there own --template
if they know about this option to log...)

Cheers,
   Jason