Some initial impressions of phases

[Matt Mackall]

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.

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

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

-- 
Mathematics is the supreme nostalgia of our time.