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

[David Pierre-Yves]

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

I had a "realistic proposal in there" what do you think about it ?:

	http://markmail.org/thread/crg2zyg3zxbifxmr#query:+page:1+mid:izyoafcvi464qq7x+state:results

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.

-- 
Pierre-Yves David