Changing default phase when no data is availble

Pierre-Yves David pierre-yves.david at logilab.fr
Tue Jan 3 07:17:24 CST 2012


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


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

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.

-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120103/6c2fb466/attachment.pgp>


More information about the Mercurial-devel mailing list