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

[Matt Mackall]

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".

-- 
Mathematics is the supreme nostalgia of our time.