Does it make sense to require --force when changing the phase from draft to secret?

[Angel Ezquerra]

On Mon, Jan 7, 2013 at 1:36 AM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
>
> On 7 janv. 2013, at 00:58, Angel Ezquerra wrote:
>
>> Hi,
>>
>> since the phase command was introduced TortoiseHg has had a "Change
>> phase" menu that lets the user change the phase of any revision. If
>> the phase moves "forward", i.e. in the secret -> draft -> public
>> direction, the phase change happens immediately.
>>
>> However, if the requested phase change would move the phase
>> "backward", TortoiseHg shows a pretty lengthy and kind of scary
>> warning asking the user to be careful. This is important when the
>> original phase is public, but I wonder if it makes sense when moving
>> the phase from draft to secret. IMHO there is little danger in that
>> phase change (unless subrepos are involved, but that is a whole
>> different subject in itself).
>
> There is less danger than for public -> draft changes. But it is still not the natural movement.
>
> (1) pull a draft changeset from a non-publishing server
> (2) make it secret
> (3) repull --> it turns draft again

This makes sense but I imagine this could be very surprising!

I've been thinking about phases for a while, in particular in relation
with subrepos. It seems to me that conceptually there is a missing
phase between pubic and draft. That "missing" phase could perhaps be
called "shared" or similar. "Shared" revisions could behave almost
like "draft" revisions but the user would know that they have been
shared with other people or other repos. This could have some nice
consequences:

- Revisions pushed to a non publishing repo would become "shared",
rather than "public". Thus, you would always be able to tell which
revisions you have shared (those that are either public or shared),
even when collaborating on a non publishing repo.

- Subrepos could use this new shared phase, by turning subrepo
revisions referenced on a parent repo into shared revisions. This
could perhaps be used to make history editing in subrepos a bit safer
than it is today. At the very least the user could tell which
revisions can be modified without being worried about breaking the
parent repo.

>> As a matter of fact, mercurial can already be configured to
>> automatically move revisions from draft to secret (when importing them
>> to mq), and it does so without warning or requiring to use --force.
>
> Please Keep MQ ou tof the equation. MQ violate several principe of Mercurial. The `mq.secret` option is here to help making MQ insanity manageable.
>

Fair enough.

>> So I'm considering removing the warning that TortoiseHg shows when
>> going from draft to secret. However that would mean behaving a bit
>> differently than mercurial, which we don't normally do.
>
> You could have a lighter warning for draft -> secret movement. Removing all warning seems a bad idea.

I have consider that option as well. Another option is adding an
explicit "make secret" command that does not show the dialog.

> Do you have a small checkbox in the commit dialog to make the commit secret? It seems the first step to improve user experience with phase in thg.

We don't, but we have a "new commit phase" setting. It is however
something that perhaps we should add.

Cheers,

Angel