Local clones and phases, mq (Re: [PATCH 1 of 5 phases] phases: exclude secret when doing a local clone)
mpm at selenic.com
Tue Jan 17 11:23:14 CST 2012
On Tue, 2012-01-17 at 14:03 +0100, Pierre-Yves David wrote:
> 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.
At least until we start advertising garbage collection, strip is not an
option for any core feature.
> On the mq topic, I'm strongly considering adding a "--private" 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.
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel