[PATCH 4 of 4 phases] phases: fix phase synchronization on push

Matt Mackall mpm at selenic.com
Fri Jan 6 16:22:05 CST 2012


On Fri, 2012-01-06 at 07:02 +0100, Pierre-Yves David wrote:
> On Thu, Jan 05, 2012 at 09:49:21PM -0600, Matt Mackall wrote:
> > On Wed, 2012-01-04 at 01:20 +0100, Pierre-Yves David wrote:
> > > # HG changeset patch
> > > # User Pierre-Yves David <pierre-yves.david at ens-lyon.org>
> > > # Date 1325635951 -3600
> > > # Node ID e2a8777c92bd878fb52add317c0dd1ab7e56dc80
> > > # Parent  e68589dcd419836ce7e2321f459ce58fe86ace2b
> > > phases: fix phase synchronization on push
> > 
> > Is this dependent on the others?
> 
> Yes, it use phase revset symbol.
> 
> > I think we still need to resolve the question: why does it make sense to
> > report any phases other than the public/draft boundary via pushkey? By
> > definition, remote has no business knowing about secret changesets.
> 
> This also implies to resolved the "do we want to allow additional phase between
> public and secret". If we do, such phase need to be exchanged too.

http://markmail.org/message/culw2mdl4rsfeak6

I think pragmatically, it will be impossible to introduce such phases
without also making corresponding future extensions to the wire protocol
in some fashion because the new phases will imply new semantics that
conforming clients will need to be aware of. So we can cross that bridge
when we come to it.

If you can think of any realistic use for this hypothetical in-between
phase today, let's here about it. Otherwise, you're over-engineering.
Don't design for all possible futures, design for likely ones.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list