Local clones and phases, mq (Re: [PATCH 1 of 5 phases] phases: exclude secret when doing a local clone)

Pierre-Yves David pierre-yves.david at ens-lyon.org
Tue Jan 17 07:03:07 CST 2012


On 15 janv. 2012, at 02:46, Matt Mackall wrote:

> On Fri, 2012-01-13 at 02:42 +0100, Pierre-Yves David wrote:
>> # HG changeset patch
>> # User Pierre-Yves David <pierre-yves.david at logilab.fr>
>> # Date 1326299187 -3600
>> # Node ID 3f56f39a5135f2253bdd8c14afe1e52a08b96ffc
>> # Parent  c47d69ce5208d5b5cfd2fb2f0f1d7a2b4795fbf5
>> phases: exclude secret when doing a local clone
>> 
>> This is achieved by denying copy clone when any secret changeset exist.
> 
> Queued, thanks.
> 
> But this reminds me of something that I've been meaning to discuss (but
> haven't brought up for fear of muddying the waters further). If you have
> a repo that you can clone via either copy or hardlink, then we might
> want to consider loosening our semantics a bit. In particular, if you
> have direct filesystem access to a repo, you can see all the secret
> changesets, so they're really not secrets FROM YOU. Should we just go
> ahead and clone everything keeping the same states in such a case?

I do not view as a good idea to have a different behavior for local clone and
remote clone.

> One invariant you could claim for clone is that if you compare what
> csets you can see in the src and dst, they should match. So if Bob looks
> at Alice's hgweb, he gets all the changesets he can see (ie not her
> secret ones). But if he clones from his own repo, he sees stuff go
> missing. And then there's the intermediate case where he clones from
> Alice over NFS: he can see Alice's secrets, but should he clone

This gray zone is pretty big and I think we should fail safe.

At logilab, most developer work on a shared server and had mains repositories
as local repo for 5 years (We switched to a mercurial server).

Moreover cloning from local co-worker clone work fairly wells as a bootstrap
for cloning big remote repo.

> Related: when you clone a local repo with mq patches, you currently get
> a repo with all the mq patches effectively qfinished. If we make mq
> csets secret and then refuse to clone them locally, our clone is even
> less complete. Arguably we should instead clone the mq state/queue (and
> corresponding phases) locally.

qclone try respond to that by removing mq changeset from clone. It try to not
pull them over the wire and strip them after clone for local repo.

> So enforcing phases here means local clones are a) less useful b) slower
> and c) heavier than they could be.

I agree this is very unfortunate. This should not impact "public server" to
"dev" clone because I do not expect public server to contains secret changeset.
But this is great deal for local developper repo and clone branching model.

> I'm honestly not sure what the right answer is here, and we can probably
> revisit this in the future.

Maybe we could have the same approach than qclone here. If there is few secret
changeset only on the top most part of the history, let's hardlink and strip.

On the mq topic, I'm strongly considering adding a "--private"[1] switch to
push. This switch will disable the exclusion of secret changeset from discovery
and allow to push secret changeset. (while not moving their phase…)

We could reuse this switch for --clone to allow an hardlink clone with secret
changeset included (handy for local clone).

We could reuse it for pull of local repo too.


-- 
Pierre-Yves

[2] could be --include-private or anything else people want to bike-shred to death.


More information about the Mercurial-devel mailing list