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

[Angel Ezquerra]

On Wed, Dec 31, 2014 at 2:39 AM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
>
>
> 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.

If I understand you correctly, we would need some sort of new
"narrowvfs" class that gets a list of files that it can actually
handle (e.g. the ones needed to maintain the working directory state)
and then enforce those on all of its operations. Then we would have
multiple such narrowvfs objects inside the localrepository, and we
would need to use one of them depending on the context. Is that what
you meant?

>> 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.

The thing I like about my original approach (the altvfs) and the new
unionvfs based approach that Matt suggested is that the concentrate
the difference between a regular repository and a fully shared
repository in a single place, the vfs. I think it makes it easy to
reasib about it and to avoid problems when people access the internals
of the localrepository class. The vfs makes sure that you access the
right files on the right location and that's it. The localrepository
users do not need to worry about anything else.

Cheers,

Angel