[PATCH] shelve: support shared repositories

Ryan McElroy rm at fb.com
Mon Mar 14 20:25:12 EDT 2016

On 3/14/2016 11:10 PM, Sean Farley 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).

Ideally this functionality would go into the share machinery in core, 
but I started some work down that direction a while back, and largefiles 
breaks. I didn't deep dive at the time.

The issue with making everything use the parent repo is 
dirstate-specific stuff -- think of the sparse extension, for example. 
So we can't just forward everything.

In fact, I wrote up a wiki page a while back outlining some of the 
bigger possible solutions to this problem: 

That is well outside the scope of this patch, which is much more 
tactical and aimed at fixing a specific pain point. It does so 
effectively with minimal outside impact, so I think we should be okay 
with this approach.


More information about the Mercurial-devel mailing list