Some initial impressions of phases

[Martin Geisler]

Jason Harris <jason at jasonfharris.com> writes:

> 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.
>
> 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? (Ie why is there a revision
> option to phase at all since the revision is the primary argument
> which must be given in any case right?)

We normally try to make -r optional, so you can use both 'hg update 123'
and 'hg update -r -10'. I use the -r form all the time to update to a
negative revision number (counted back from tip). I could also use '--'
there, though, so it's probably just a bad habit.

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

Btw, did you notice that we have no 'bookmark' command? We only have
'bookmarks', in plural. We have both 'branch' and 'branches', and 'tag'
and 'tags', though.

Maybe 'hg phase' could manipulate the current phase, and 'hg phases'
could print the heads of each phase:

  $ hg phases
  public:  1000, 1010
  draft:   1015
  private: 1017, tip

Not sure how useful that is, especially when 'hg log -r "draft()"' can
give a better changeset listing.

> However, Commit, Clone, push, pull, rollback, update, branch, and
> revert do report information. (Obviously commands like Incoming,
> outgoing, log, status, etc report information.)
>
> 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.

I've always liked how Mercurial is terse in it's output -- if I run 'hg
add foo' then I don't need output when it worked. If I run 'hg add dir/'
then it makes sense to explicitly tell me the files added inside dir.
This works great.

Now, for 'hg phase', I feel that output could make sense. It's changing
a state that is not very visible by default. The most similar thing is
'hg branch' which changes the current branch in the dirstate and which
takes effect on next commit. I know 'hg phase' changes the state
immediatedly, but the hidden aspect of it makes me thing that we want
output here.

>>> Point 10.
>>> 
>>> This still has public < draft < secret. Wasn't it decided to use
>>> private rather than secret?
>> 
>> Well, the choice was public/draft/secret + short opts or
>> public/draft/private + only long opts. Since insufficient enthusiasm
>> was expressed for the latter, we're sticking with the former.
>
> What? I thought most everyone commenting on email preferred the second
> one, or they had a different opinion. Some people wanted different
> names, but of the names which most people agreed on, secret was not
> the preferred name. For the reasons I and others have articulated it's
> a bad name.

Agreed -- I can make a patch to change the name if that would be okay?

>>> Point 11.
>>> 
>>> A local clone resets the phase to public. It shouldn't.
>> 
>> Debated elsewhere, many arguments pro and against exist.
>
> Well, I believe it's going to cause problems in practice. Local clones
> for experimentation are going to be hampered with having to manually
> adjust the phase for each clone.

It was my understanding from the beginning that draft changesets are
meant to be shared and that they were meant to be shared *as draft*.
This is why I think they should remain drafts when you clone. Public
servers can set publishing=True so that everything pushed there becomes
public.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://www.aragost.com/mercurial/customer-projects/