[PATCH] shelve: support shared repositories

[Oleg Afanasyev]

With my limited experience with mercurial repo internals, dirstate and cache
probably belong to share's private data as well as bookmarks depending on the

creation option.

I'm fiddling with approach where repo.vfs is pointing to shared location to
see if it could be changed.

The side effect could be that extensions that work with shared repositories would
most likely break with such change.

On 3/14/16, 11:10 PM, "Sean Farley" <sean at farley.io> wrote:

>
>Oleg Afanasyev <olegaf at fb.com> writes:
>
>> # HG changeset patch
>> # User Oleg Afanasyev <olegaf at fb.com>
>> # Date 1457972723 25200
>> #      Mon Mar 14 09:25:23 2016 -0700
>> # Node ID 6ec353e7cc031f453d26925fcbf15a035aaf2c90
>> # Parent  1c658391b22fb4d98ccfb60c0e57315b55634117
>> shelve: support shared repositories
>>
>> Shelve will use shared data instead of its own shelves. That would
>> allow moving changes from share to share using shelve.
>>
>> When unshare is performed shelve will not be cloned to new repo. That
>> would change behaviour from what it is doing now e.g. shelves created
>> in share will disappear when unshare is done vs now shares have their
>> own shelves.
>>
>> diff --git a/hgext/shelve.py b/hgext/shelve.py
>> --- a/hgext/shelve.py
>> +++ b/hgext/shelve.py
>> @@ -61,6 +61,12 @@
>>  
>>  backupdir = 'shelve-backup'
>>  
>> +def shareawarevfs(repo):
>> +    if repo.shared():
>> +        return scmutil.vfs(repo.sharedpath)
>> +    else:
>> +        return repo.vfs
>> +
>
>This is beginning to become a pattern in a few extensions now. I think
>that this is a good example of something that should go into core so
>that all extensions can benefit.
>
>Is there a reason 'repo.vfs' can't easily return the shared path? When
>does it make sense for it to return the 'parent' repo path?
>
>Off the top of my head, I would expect 'repo.vfs' to return the repo I'm
>currently in (i.e. the repo.sharedpath).