Having more than three phases (was RFC: Phase UI (revset, phase command and others))

[Augie Fackler]

On Tue, Jan 3, 2012 at 12:52 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Tue, 2012-01-03 at 10:38 +0100, Pierre-Yves David wrote:
>> On Thu, Dec 29, 2011 at 01:22:51PM -0600, Matt Mackall wrote:
>> > On Thu, 2011-12-29 at 14:59 +0100, Pierre-Yves David wrote:
>> > > On Wed, Dec 28, 2011 at 11:53:23PM -0500, Augie Fackler wrote:
>> > > > On Dec 28, 2011, at 5:36 PM, Matt Mackall wrote:
>> > > > >
>> > > > > On Wed, 2011-12-28 at 08:49 +0100, Gilles Moris wrote:
>> > > > >>> I find this spare number a quite interesting topic. But I did not processed
>> > > > >>> enough high priority item about phase to care about it yet. If you want to
>> > > > >>> drive a discussion on the topic of "what more phase could be useful for and
>> > > > >>> what are the draw back", go for it ! I'll try to feed it.
>> > > > >>>
>> > > > >>
>> > > > >> No, I do not have any additional phase in mind. Just the idea that we may be
>> > > > >> into trouble if we find an interresting intermediate phase concept after 2.1.
>> > > > >
>> > > > > If we do, we'll almost certainly have much bigger problems than simply
>> > > > > fitting it between the existing phase numbers. So I think spacing out
>> > > > > the phase numbers (in 1980s BASIC style!) has a 95% chance of being
>> > > > > pointless over-engineering that will get in our way later.
>> > > >
>> > >
>> > > > Could we avoid exposing the phase numbers? That'd get us the best of both
>> > > > worlds, right? What does exposing phase numbers in the public UI (through the
>> > > > templater) get us?
>> > >
>> > > Phase number have a nice property, they are sortable.
>> > >
>> > > The phase number are exposed in two critical place that would prevent addition
>> > > trivial of additional phases.
>> > >
>> > >     - the phaseroots files store data in the form: "phaseidx nodehex\n"
>> > >     - the phases namespace on pushkey refer to phase with they phase index.
>> >
>> > Not really sure why this is necessary. After all, we only share public
>> > and draft, so only the public/draft boundary every needs to be exposed
>> > remotely.
>>
>> Exchanging secret boundary are actually useful to detect secret changeset that
>> exist elsewhere. The current behavior when such (not so) secret changeset are
>> detect is to set them in draft phase (at least).
>
> ????
>
>> But I think the main question here is: Do we want to allow extension of the
>> number of phase later ? This additionnal phase might be added by both core or
>> extension. Such phases extension is clearly not a priority but should be settled
>> now. I'm thinking about additional use for phase for several month, I came the
>> the view detailled bellow:
>>
>> Phase are not suitable for:
>>
>>   Implementing a trash phase to mark deleted changeset: phase are designed to
>>   move a given direction (old phase > new phase) and moving changeset from
>>   draft or secret phase to a trash one will break this rule.
>
> ..except that every alternative I've seen proposed (obsoletion markers,
> dead heads) is MORE ill-suited. We made the rules, we can break them
> when appropriate. And I really don't see much wrong semantically with
> saying "these draft/secret changesets are to henceforth be ignored for
> log/push/pull and are subject to GC".

I'm pretty sure we need to communicate trashed/obsoleted state as well
- otherwise how can I publish RFC draft changesets for people to
examine, and then have them get "deleted" later?

>
> --
> Mathematics is the supreme nostalgia of our time.
>
>