Call for discussion: Phase names

Pierre-Yves David pierre-yves.david at ens-lyon.org
Mon Jan 9 19:01:21 CST 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 9 janv. 2012, at 23:25, Matt Mackall wrote:

> [forwarded back to list]
> 
> On Mon, 2012-01-09 at 22:55 +0100, Pierre-Yves David wrote:
>> On 9 janv. 2012, at 21:52, Matt Mackall wrote:
>> 
>>> On Mon, 2012-01-09 at 20:28 +0100, Olav Reinert wrote:
>>>> Hi all,
>>>> 
>>>> At the 2.1 mini-spring in Zürich last week-end, the names of the
>>>> phases were discussed quite a lot, and it has also been a topic of
>>>> much discussion here on the mailing list.
>>>> 
>>>> In order to reach a useful consensus in time for the 2.1 code freeze
>>>> in mid-January, Pierre-Yves DAVID from Logilab has asked me to
>>>> organize a conclusive discussion to decide on the phase names to use
>>>> in the final release.
>>>> 
>>>> 
>>>> The current (unacceptable) naming scheme is as follows:
>>>> 
>>>>   Name    Immutable   Shared
>>>>   public      X         X
>>>>   draft                 X
>>>>   secret
>>>> 
>>>> (Even though the names of the changeset properties assigned to the
>>>> phases (immutable and shared) have also been debated, their meaning is
>>>> not disputed.
>>>> 
>>>> Most people seem to agree that "draft" is a good name for the middle
>>>> phase, because it implies a work-in-progress that may be shared. The
>>>> name "public" is disliked by some because it doesn't convey
>>>> immutability, which is an important and distinguishing property of
>>>> that phase.
>>> 
>>> Changesets become immutable because they've been made public (ie by
>>> pushing them to a public server), not vice-versa.
>>> 
>>> I basically think 'public' and 'draft' are frozen. Not interested in
>>> 'published'.
>>> 
>>>> The name "secret" is disliked because to some it suggests enforcement
>>>> of confidentiality (i.e., that it's safe to check in trade secrets or
>>>> nuclear launch codes), which is not the case, and not intended,
>>>> either.
>>> 
>>> I've yet to see any good articulation of why we'd want to expose hashes
>>> from this phase over the wire. It continues to seem self-evidently wrong
>>> from a design perspective to do so: the client simply has no business
>>> having visibility into these changesets. I will continue to be unhappy
>>> with this regardless of what the phase is named.
>> 
>> 
>> Secret changeset are not excluded from discover if they both exist on
>> local and on remote.
> 
> And what is the rationale for that? That -also- seems obviously wrong.

The real rational for that is the implementation: To ensure secret changeset are not exchanged:

* For incoming discovery, remote lies on it's actual heads and only returns it's visible one. So discovery only start from not secret heads.
* For outgoing discoverr, the heads of the set we are looking for are altered so it only define non secret changeset.

So they are -never- any secret changeset in outgoing or incoming part of discovery.

The case i describe above is:

	While local is trying to discover the common set of known changeset, local ask remote "Do you know this 'X' changeset" where X may be secret. And remote response yes to such question if he actually have it.

This result in the behavior I described in my previous email. let me rephase it:

	If a changeset exist in both local and remote, the discovery code put it in the set "commonly" know changeset. This does not implies anything with the fact he his exchanged.

If we really want to prevent this I see two way to achieve this:

	[1] prevent relocate to ask if locally secret changeset do exist remotly.
	[2] make remote lies on the fact that he know about a remotly secret changeset

	In both case this requires extra works for  localrepo.addchangegroup and phase syncing to ensure that adding draft changeset above a secret one work properly. 

But I have yet to be convinced this is required:

The case where you have a changeset secret on both will be pretty rare.
The fact that people will want to have secret changeset on a main public server itself is strange.

Lay down security to ensure secret changeset are totally insulated will get in the way of a way to push//pull any secret changeset when we really want.

example: "hg push -f qtip" or "hg incoming --secret"


> I see: the rationale is it saves transmit time for the edge case of
> "pushing changeset that are already present but secret on target".
> That's a fairly contrived scenario, and a poor reason to make this
> design choice. And it's almost certainly going to cause trouble.

It's neither a rational or a design choice. It is a side effet. The current discovery without further alteration may find common secret  changeset. And people asking remote.getbundle() about a specific changeset will get it, whatever it's phase.

> People today do things like 'hg id -r tip remote' to figure out what
> their incoming changeset group is going to look like, and if we don't
> actively hide these changesets from remote clients, we're breaking that.

Those people should use incoming…


> Similarly, if discovery says there are remote csets and we get an empty
> changegroup, we're going to upset people using 'hg summary --remote'.

Discover does not say that. Discovery will either:

	- not see the secret changeset --> no remote cset to pull
	- See a changeset he already have --> no remote cset to pull

The only relevant issue I can think of is that hg outgoing//summary does not mention hint that:
	"hg push will make such changeset available for pull on remote."

> If we have to resend changesets because they happen to exist but are
> secret remotely, then I'm absolutely fine with that if it means we can
> have them actually be properly isolated.

For me this third phase is just a safety barrier to ensure changeset are not exchanged by mistake. Having a much stronger semantic requires more work and I not yet convinced this stronger semantic is more useful that the safety barrier one.

- -- 
Pierre-Yves David


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJPC43hAAoJELAL+T1/FX642UwQAKdzTdpsHOeTMzp7Ug90zgG7
+z9QbQ8MvQck1uyCXPyg+NZSs727GBpGvCLuCvaz0YY/dised87PcjEG2JqSscrF
OgIIS6tO1NYrPegQwU12KSS+ay7k8xnm2gpF7iA7SkIpY8qucqcxU/0JBTMM1r20
c1yFtEVnttZf9Li1z+Dh8sGwOqYDiQmCvkTVn3VND2mxswQfdaVj8wD6VL8Oh6Wk
P4hwLIrkVB15paZqGRUiriyJNTJj6Nn2+pAEjBAM+/yg7NeHKG1i4FZGuhQnKM83
xGAEfoHtPbX6p4NV9cTTiMSS4GG4WD0JLu9gNy0/iJ1pAKVCMhSo9rXbONRCgo1S
911Aye67KZP5AqGyEuOtJc3YxTFjlVzfbnydnocJ6iKT0jmuhgnnrI3UdAaR3gBP
JDEJmC0RlPpkganwMB3Lvl3inrp89Whjr197lRk9+53/1DVqlHpLLElCyX10pwqP
mSfeZwuOPODYDIYphtGCKG8LmKroyCrZ958QGtOA2rav+2J6e+nl809lf7v7DfCh
QrlahPey9v0WSbfQ04bLmljPdDw9Mx3eUFt3CN/6mCvn2Y65HLnwujbGyB6IkBX4
rPH4QL3qDxjDrrSYc/o4oBE1oCCtPp/m0G0KQFmugOtcH+mGW8Nj1sVRqBwA5k+E
hW/XWYdmjTyDwxRYZ5u3
=K54w
-----END PGP SIGNATURE-----


More information about the Mercurial-devel mailing list