[PATCH 1 of 6 V2 RFC] localrepo: introduce shared method to check if a repository is shared

[Pierre-Yves David]

On 12/30/2014 04:46 PM, Angel Ezquerra wrote:
> On Tue, Dec 30, 2014 at 11:00 PM, Pierre-Yves David
> <pierre-yves.david at ens-lyon.org> wrote:
>>
>>
>> On 12/26/2014 03:46 AM, Angel Ezquerra wrote:
>>>
>>> # HG changeset patch
>>> # User Angel Ezquerra <angel.ezquerra at gmail.com>
>>> # Date 1419117550 -3600
>>> #      Sun Dec 21 00:19:10 2014 +0100
>>> # Node ID b213f4439d5427cfff6c7fa28927c25e4422a948
>>> # Parent  67d63ec85eb72187508692e52f14be46101707a5
>>> localrepo: introduce shared method to check if a repository is shared
>>
>>
>> According to the "Localrepo Diet Act" adding rarely used method on the
>> localrepository class is a criminal offense. Can we stick this as a function
>> in the shared extensions instead?
>
> The problem is that the localrepository.sharedpath property is not
> private and people are already using it, comparing it to
> localrepository.path, to check if a repository is shared. I think this
> is bad form and also limits the ways in which we can change the way
> shared subrepos are implemented. My solution was to commit the crime
> and add a new method to localrepository :-> (then we could make
> sharedpath private). Do you think adding a function in the share
> extension would solve the problem? My feeling is that it would not.

The function will behave as the method:

   shared(repo) → None or 'shared' or 'full'

And it will be requested to use it instead of check attribute

>> Moreover, we recently added the option to share bookmark. Could we use a
>> different "type" for this case too?
>
> Possibly. Other options would be for the share method to return a list
> of what is shared.

Lets keep things simple for now. Take the simpler path that fits our 
needs (whatever it is) but you should probably fire-trial your new toy 
on existing usecase before introducing the '
full' things.

-- 
Pierre-Yves David