Some initial impressions of phases

[Jason Harris]

Thanks for the comments Martin!

On Jan 24, 2012, at 10:57 AM, Martin Geisler wrote:

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

True, but update can't apply to a range. Eg "hg update -r 650:tip" makes no sense.

(But I get your point...)

>> As an aesthetic thing I think separate
>> commands would be better. Or at least have the main argument be the phase. Eg
>> 
>> (a) hg phase --rev 950:tip --force private
>> 
>> rather than the current
>> 
>> (b) hg phase --force --private 950:tip
>> 
>> Form (a) is I believe just more "mercurial-like", eg "hg push --rev 950:tip
>> --force myserver", or "hg status --rev 950:tip MyDir/Classes" or qimport, etc
>> etc. Don't most other commands which operate on a range of revisions work in the
>> way (a) does?


On balance, I still feel that we should go with form (a) of the command.


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

Actually I *didn't* notice that bookmark was aliased to bookmarks until you
pointed it out above.


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

Actually ideally we would use subtle colors in our log commands to indicate
phase. I think 'hg log -r "not(public())"' is even better and it would be nice to
have the phase in there...

I guess the color extension will be updated appropriately and many
"in-the-know" people will switch that extension on.


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

Yep. That would make things a lot better IMHO.

Cheers,
  Jas