RFC: Phase UI (revset, phase command and others)

Jesper Schmidt schmiidt at gmail.com
Mon Jan 2 17:05:41 CST 2012


On Wed, 28 Dec 2011 00:34:32 +0100, Pierre-Yves David  
<pierre-yves.david at ens-lyon.org> wrote:

>
> On 27 déc. 2011, at 23:59, Jesper Schmidt wrote:
>
>> On Tue, 27 Dec 2011 00:11:12 +0100, Pierre-Yves David  
>> <pierre-yves.david at ens-lyon.org> wrote:
>>
>>> Phase name
>>> ============
>>>
>>> The current naming scheme is:
>>>
>>>           immutable shared
>>>   public:     X        X
>>>   draft:               X
>>>   secret:
>>>
>>> The two rules leading to such scheme are:
>>>
>>> 1) Thou shalt not pick phases name whose initial clash with each other.
>>>   (eg: no Public/Private)
>>>
>> Too bad, because I prefer 'private' over 'secret'. When I hear secret,
>> I cannot help thinking about security levels, which is not very helpful
>> in this context. Private, on the other hand, leads me in the right
>> direction as being the opposite of public.
>
> We won't have both private and public as phase name. If you like private  
> you need to make proposal to replace public.
>

I have a suggestion, but first a little motivation.

Naming the final phase 'public' is a bit problematic IMO, since the user is
also going to consider a 'draft' changeset public, because it can be  
shared.
What really differentiates the final phase from the other two is  
immutability.
Therefore I suggest that we call the final phase 'stable', since it  
provides
a stable foundation to build on, which is not the case for other two.

I can now rename 'secret' changesets to 'private' changesets without  
breaking
the rules ;-)

Naming scheme proposal:

            immutable shared
    stable:     X        X
    draft:               X
    private:

>
>>> Phase command
>>> =============
>>>
>>> Phase of changeset can be manually altered with the "hg phases" command
>>>
>>
>> Have you considered using a verb instead of a noun? Nouns are normally  
>> used
>> to show stuff while verbs indicate that the command changes some state.
>>
>> What about using 'hg promote' to manually promoting a changeset to a  
>> higher
>> phase and 'hg demote' to manually demoting it to a lower phase. I like  
>> the
>> fact that you need to express your intention (promoting or demoting)
>> explicitly, when you are assigning phases manually.
>
> This proposal is interesting at first glance but getting the --exact  
> behavior will require to use two command which don't seem very  
> practical. But "promote" and "demote" verbs are interesting.
>


-- 
Jesper


More information about the Mercurial-devel mailing list