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

[Pierre-Yves David]

On 12/30/2014 05:07 PM, Angel Ezquerra wrote:
> On Tue, Dec 30, 2014 at 10:58 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 1419360788 -3600
>>> #      Tue Dec 23 19:53:08 2014 +0100
>>> # Node ID bb70464b9121df236db6d264d57b6f56ad78cd3b
>>> # Parent  dd180345dd166fc51d061a8041e014f320c20d6c
>>> share: add "full share" suport
>>
>>
>> I've been through the RFC, The vfs dispatcher is a bit scary and can
>> probably be avoided, the multi locking is less scary and could be okay.
>>
>> But this series ring some familiar bells. You are going through some dancing
>> to handle "few key files that represent the working copy state". I've
>> recently been thinking about how to move toward a newer repository format
>> that would allow fully atomic transaction for new data type (phases,
>> bookmarks, obsmarkers) and efficient sharing. One of the way to improve the
>> situation is to improve "tagging". Knowing what file are critical for the
>> transaction, which one depends/control the working copy etc.
>>
>> In my current opinion, the best way to achieve this is to have distinct vfs
>> object for distinct category of file. This would remove the needs for the
>> unionvfs withcraft.
>>
>> What do you think?
>
> So your proposal would be to remove the existing vfs localrepo
> property and replace it with multiple vfs objects, one for each
> related group of files? If that is what you propose it could be a way
> to avoid the unionvfs. That being said there are quite a few uses (not
> a lot, but not few either) of the vfs property in the code, so this
> sort of thing would require a number of changes to the code.

The localrepo.vfs would not necessary disappear. we already have other 
vfs alongside it (wvfs, svfs). We would introduces a new vfs attribute 
for the category of file you already isolated and use it for these file. 
It should not be too complicated since you already went through the 
trouble of isolating the list of affected file.

> To be completely honest my goal is to implement the subrepo store that
> we discussed in the Munich sprint. Given the bandwidth that I will
> have in the next few months I worry that trying to do this sort of big
> architectural change might stop me from reaching that goal. I don't
> want to sacrifice the quality of the code of course but I wonder,
> isn't using a unionvfs an implementation detail? The important thing
> is the behavior of the full shared repos. The implementation itself
> can be changed later, can't it?

the unionvfs is a bit scary and looks fragile, the new vfs approach is a 
step in a right direction and does not introduce new magical class. The 
point here is not to isolate all possibles category and adds handful of 
new vfs. Just change the minimal amount of call to get you code to work.

-- 
Pierre-Yves David