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

[Laurens Holst]

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.

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

Is it really needed? :/

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

>> On the other hand, the previous statement also shows that I have had a need to alter the history after I’d tagged it, but before I pushed. These changesets are not public, so I *should* be able to safely alter them, as long as I remove the tag too.
> You can alway manually move phase. altering tagged changeset should be rare enough to justify manual movement.

Fair enough.

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

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

~Laurens

-- 
~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, developer, Utrecht, the Netherlands
Website: www.grauw.nl. Working @ www.roughcookie.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4332 bytes
Desc: S/MIME cryptografische ondertekening
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20111227/4fc46e1d/attachment.p7s>