RFC: Phase UI (revset, phase command and others)

Matt Mackall mpm at selenic.com
Thu Dec 29 13:22:51 CST 2011


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.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list