[PATCH 4 of 4 phases] phases: fix phase synchronization on push
mpm at selenic.com
Sat Jan 7 19:38:21 CST 2012
On Sat, Jan 07, 2012 at 05:55:29PM +0100, David Pierre-Yves wrote:
> On 6 janv. 12, at 23:22, Matt Mackall wrote:
> >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.
> >I think pragmatically, it will be impossible to introduce such phases
> >without also making corresponding future extensions to the wire
> >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
> >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.
> I had a "realistic proposal in there" what do you think about it ?:
Not excited about it.
> We had a long discussion about phases yesterday at the Zurich mini-
> sprint. In particular about other usage for phase. Olav from Aragost
> made the argument that such functionality is better implemented by
> hooks, dedicated extensions or tool external to the dvcs itself. In
> particular, Suggested usages often try to register property (e.g.,
> "passed QA" or "production ready") on a specific node and not just a
> whole consisted part of the dag. Just because node X passes QA
> doesn't imply that its ancestor did - in fact, it is almost
> certainly not the case.
> He was pretty convincing and I'm starting to think that the current
> three phases is a model which is better kept simple.
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel