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

[Pierre-Yves David]

On 27 déc. 2011, at 23:31, Laurens Holst wrote:

> Op 27-12-2011 20:26, Pierre-Yves David schreef:
>>> But it may also have a bad side-effect: I often make a backup clone before I do a history-modifying operation. As this will become more troublesome, users may start to omit it, which leads to a higher risk for loss of history.
>> 1) You backup clone is a read-only operation and won't alter the phase of your working-repository changeset.
> 
> Ok, I see now. So pull does upgrade the changeset to public, but only in the backup repo.

Pull from publishing changeset "kind of" move changeset from draft to public. But actively using phases property and still having active&publishing repo seems a bad idea.

Note that: public < draft < secret. Moving from draft to public is more about "downgrading".

>>> Probably mq should remember the original phase.
>> Such behavior is definitely possible. I doubt to have the time to implement it before 2.1.0 freeze through are you motivated enought to send patch regarding this part ?
> 
> Uff I’m already spending so much time on these few patches I submitted earlier, while I was planning to work on another project during the vacation :).
> 
>>>> Tag:
>>>> 
>>>>    Current history rewriting extension does not handle tag.
>>>> 
>>>>    As suggested by Matt during 1.9 sprint, hg tag should make changeset public.
>>> Should read: “should make the tagged changeset public”.
>> yes (both tagging and tagged changeset probably)
> 
> If you make the tagging changeset public then if I make a mistake when tagging I can’t rollback and do it over.

Wrong, using rollback will just work here. `hg rollback` will removing the tagging changeset and restore the phase as before the tagging.

>>> I guess on one hand it is useful; I too have been bitten by rewriting history after I had tagged a changeset, making the tag invalid (and then subsequently pushed it without noticing).
>> There is two reasons for such proposals:
>> 
>> 	1) We you tag something you usually mean: "I would like to give him a name to this changeset to make him a notable step of my immutable history."
>> 	2) Most history rewriting extensions doesn't handle tag well.
> 
> 2) can be fixed.

Last time I checked, code didn't wrote himself during the night :-)

>>> Mh. So if I use -C on top of a secret changeset, the secret changeset will become draft the next time I commit? That seems odd. What’s the use case for this option?
>>> 
>>>> Exact help text is to be tuned to remove the confusing lower//upper phase stuff.
> 
> Ok, looks like I misunderstood ‘max’, as the max is not public but secret.
> 
> So if I use -C on top of a secret changeset the secret changeset will stay that way.

absolutly. (reminder phase < draft < secret

>> Yes this is a proposal to handle the usecase of "I want my next commit in phase X"
> 
> Looks good. However:
> 
>> -p --public   Set target into public phase
>> -d --draft    Set target into draft phase (or leave it in lower phase (public))
>> -s --secret   Set target into secret phase (or leave it in lower phase (draft
>>               and public))
>> 
>> 
>> -b --backward reverse the logic, phase are left in upper phase, not lower
>> -e --exact    all target changeset are exactly set in the specified phase
> 
> The whole backwards and exact thing is confusing to me.
> 
> Why not just always use exact, and abort when the user attempts to change the phase from public to draft, or draft to secret? You can provide a --force option to let the user override this.

I add this proposal to the list of interesting one.

-- 
Pierre-Yves David