[PATCH] hg: support for auto sharing stores when cloning

Matt Mackall mpm at selenic.com
Tue Jul 7 14:35:04 CDT 2015


On Fri, 2015-07-03 at 14:29 -0700, Gregory Szorc wrote:
> On Fri, Jul 3, 2015 at 2:19 PM, Gregory Szorc <gregory.szorc at gmail.com>
> wrote:
> 
> > # HG changeset patch
> > # User Gregory Szorc <gregory.szorc at gmail.com>
> > # Date 1435958308 25200
> > #      Fri Jul 03 14:18:28 2015 -0700
> > # Node ID 17d2b4b8eaaf8bab93d75cfded8042e2d82a3bff
> > # Parent  84518051bc3b851f736872df045d662de548b3c9
> > hg: support for auto sharing stores when cloning
> >
> 
> 
> First, mpm gave verbal approval for this feature in Montreal. However, it
> was high level approval only and the details were never worked out. This
> patch probably needs some bikeshedding on:

Ok, there is indeed a lot going on here.

If I clone something that I have a stale local copy of, will a pull be
run to make sure the share is up-to-date? Doesn't look like it?

> * config option names ("share" vs "clone" etc)

The share section seems appropriate (see below). We might want to make
"basepath" into "pool" or something.

Re: namemode, we usually do "repo identity" based on the hash of
changeset 0. This still requires contacting the server to discover the
root hash, but we could use this to do a naming-insentive scan of the
share pool for matching repos.

> * should flags be added to `hg clone`

I'd say no. It's easier to add flags later than take them away.

> * should the path to the shared repo be printed

Some sort of message that sharing is happening is necessary, I think.

> * should we require the "share" extension be enabled

For now, yes. There are issues with locking and strip and such that mean
that people -do- need to be aware of the mechanics here.

Docs probably ought to be in share for now too.

> * should bookmarks be shared by default

It should match whatever share does. We might consider having a config
flag though.

> Also, the role of the "share" extension is kinda funky. A lot of the share
> functionality is built into core. Before bookmark sharing was added, the
> share extension pretty much just exposed the `hg share` and `hg unshare`
> commands (see https://selenic.com/repo/hg/file/5a4d1a6c605f/hgext/share.py).
> I can argue that the bookmark behavior changes should be in core and not
> the share extension because weird things will happen if the share extension
> is deactivated.

Basically the share extension should only hold the command and any
command wrappers.

-- 
Mathematics is the supreme nostalgia of our time.



More information about the Mercurial-devel mailing list