[PATCH 5 of 6 RFC] share: add support "full share" suport

Angel Ezquerra angel.ezquerra at gmail.com
Mon Dec 29 13:40:06 CST 2014


On Mon, Dec 29, 2014 at 8:09 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Wed, 2014-12-24 at 13:05 +0100, Angel Ezquerra wrote:
>
>> A "fully shared repository" is one shares _everything_ with its source
>> repository including bookmarks, mq patches and configuration files.
>
> Really curious what the story is for sharing mq state.

As you know this is related to my "subrepo cache" proposal with which
I want to make it possible to:

- Remove unused subrepos from the working directory
- Make the .hg folder of a repository self contained, even if the
repository has subrepos

To do so, the idea is to use full shares to create a "subrepo cache"
(or maybe a better name for it is a "subrepo store"?). The actual
subrepo repositories would be stored on the subrepo "store" while
their working directories pointing to a particular revision would
still be located in the parent repository's working directory.

In that context, it seems that the whole mq patches folder should be
kept on the subrepository source, not on the share. That way if you
delete the subrepo from the working directory you can get it back just
as it were by recreating the share later on.

Obviously this is not meant to let a user create two copies of the
same repository n which it can have separate mq series. That being
said the unionvfs class this is based upon could be used for to create
shares that do not share their mq patches. It is just a matter of
changing the selection function to include the patches folder (or any
other set of files) in the share or in the source. We could devise
different flags to select what to share.

Maybe these special "full shares" that are to be used for subrepos
should not be exposed on the hg share extension command line? I kind
of like them because they let you have the working directory in one
location and the actual repo somewhere else, but I can see how they
could be a bit dangerous unless you keep the repository source at the
null revision...

Sorry for the lengthy reply. I know you are busy but I don't know how
to better explain it...

Cheers,

Angel


More information about the Mercurial-devel mailing list