Changing default phase when no data is availble

[Matt Mackall]

On Tue, 2012-01-03 at 14:17 +0100, Pierre-Yves David wrote:
> After using default branch as my default mercurial for some time I think we need
> to change the phase picked for changeset when no phase data are available for
> backward compatibility reason.
> 
> Example scenario
> 
>     1) clone a repository (changeset M is retrieved)

I assume this is 'X'.

>     2) make a new commit  (changeset Y is retrieved)
> 
>     then:
> 
>     A) Is X mutable ?
>     B) Is Y mutable ?
> 
>     later:
> 
>     3) pull again
>     C) Is X mutable ?
>     D) Is Y mutable ?
> 
> 
> We distinct 4 Cases:
> 
>     Old: An old client is used for all operation.
>     New: An new client is used for all operation.
>
>     In Public and Draft case, an old client is used for (1) and (2), then a new
>     client is used for (A, B, 3, C and D).
> 
>     Public: the lack of phaseroots data is seen as: "everything as public"
>     Draft:  the lack of phaseroots data is seen as: "everything as draft"
> 
>          before push       after push
>             (A)     (B)     (C)     (D)
> Old        yes      yes     yes     yes
> Public      no       no      no     no
> Draft      yes      yes      no     yes
> New         no      yes      no     yes

Now you've lost me: nowhere in your scenario do you mention push. So I
have no idea how your scenario relates to your table.

But as far as I understand, the issue is "in the old world, I could
modify changesets that I'd pulled/pushed to a server and now I can't".
Umm, yes, that's the whole point.

> The current default is "Public", I'm advocating a shift to "Draft".

Then this will be both useless and dangerous for the N years it takes
Bitbucket and Google and Kiln and whoever else to implement phase
support.


> The table above show that the "in doubt it's public" succesfully prevent the
> user to rewrite public (as in exist remotely) changeset but it also prevent
> rewriting local changeset (which should be draft) forever unless it move phase
> manually. Requiring user to move phase manually after mercurial upgrade is imho
> *very bad* as it will require user to understand phase even when they have no
> reason to be aware of them.
> 
> On the other hand, "in doubt it's draft" does not prevent the user to rewrite
> local changeset but fail to see X as immutable until the first pull (or push).
> However once a remote contact is established (pull or push), phase data get
> properly synchronized. Using such approach will ensure we smoothly get the new
> behavior without impacting standard user. After update, we only have a small
> window before the first push/pull, where a new mercurial is as unsafe than
> previous version.
> 
> If people agree with me, patches in such direction will land shortly.
> 
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel


-- 
Mathematics is the supreme nostalgia of our time.