Changing default phase when no data is availble

timeless timeless at gmail.com
Wed Jan 4 06:15:32 CST 2012


For me, while I was doing Gecko work, my pending work was in mq, so if
I update from pre-phase Hg to Phase Hg and my MQ commits are properly
mapped to draft, I'm good.

Release Notes for the new Hg could say:
If you have any non published commits and intend to mutate them, then
you should either import them into MQ or bundle and strip them. If you
don't do this, you won't be able to mutate your commits after you
upgrade.

On 1/3/12, Matt Mackall <mpm at selenic.com> wrote:
> On Tue, 2012-01-03 at 19:36 +0100, Pierre-Yves David wrote:
>> On Tue, Jan 03, 2012 at 12:23:29PM -0600, Matt Mackall wrote:
>> > 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.
>>
>> s/push/pull, in other word
>>
>>          before (3)        after (3)
>>             (A)     (B)     (C)     (D)
>> Old        yes      yes     yes     yes
>> Public      no       no      no     no
>> Draft      yes      yes      no     yes
>> New         no      yes      no     yes
>>
>> >
>> > 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.
>>
>> No the whole point is: With the current code, once I upgrape my mercurial
>> version to 2.1.0 can't modify changeset I did not pulled/pushed yet.
>
> In other words, it "fails safe". Which matters for all of 30 minutes
> after upgrade and/or one manual command. I don't think this is worth
> worrying about.
>
>> >
>> > > 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.
>>
>> No, you got it wrong:
>>
>>     My proposal is content of *local* repository are seen as draft if no
>> phases
>>     data is available.
>
> Ok, then this is still dangerous. User who knows he's using 2.0 and thus
> 'rebase is safe' can accidentally rebase an entire public branch if he
> happens to be using an 'old' repo.
>
> --
> Mathematics is the supreme nostalgia of our time.
>
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>

-- 
Sent from my mobile device


More information about the Mercurial-devel mailing list