[PATCH 1 of 3 RFC] vfs: add "vfs" fields to localrepository for migration from "opener"
Adrian Buehlmann
adrian at cadifra.com
Tue Jun 26 05:59:21 CDT 2012
On 2012-06-26 11:22, FUJIWARA Katsunori wrote:
>
> At Mon, 25 Jun 2012 23:27:06 +0200,
> Adrian Buehlmann wrote:
>>
>> On 2012-06-21 12:47, FUJIWARA Katsunori wrote:
>>> diff -r 88f650208c32 -r 11873b223a9c mercurial/localrepo.py
>>> --- a/mercurial/localrepo.py Wed Jun 20 12:30:16 2012 -0500
>>> +++ b/mercurial/localrepo.py Thu Jun 21 19:41:03 2012 +0900
>>> @@ -38,7 +38,9 @@
>>> self.origroot = path
>>> self.auditor = scmutil.pathauditor(self.root, self._checknested)
>>> self.opener = scmutil.opener(self.path)
>>> + self.vfs = self.opener
>>> self.wopener = scmutil.opener(self.root)
>>> + self.wvfs = self.wopener
>>
>> I know it's probably the "plan", but I don't like a name "wvfs".
>>
>> My brain is almost reaching for the canonical "wtf", similarity-wise.
>>
>> Likewise, svfs is not something I'd like to have to look at in broader
>> scope.
>>
>> Perhaps dropping the "v" might help:
>>
>> wvfs -> wfs
>>
>> svfs -> sfs
>>
>> Almost every file system is virtual in some sense, isn't it? So I think
>> "virtual" is a bit meaningless.
>>
>> But we might go a bit longer:
>>
>> wvfs -> workingfs
>>
>> svfs -> storefs
>>
>> Compare: workingctx in context.py.
>>
>> If you want to insist on "vfs":
>>
>> wvfs -> workingvfs
>>
>> svfs -> storevfs
>
> Thank you for your comments.
>
> What about renaming below ?
>
> opener -> repovfs
Hmm. Usage of that would read a bit silly. Consider:
file = repo.opener('bookmarks.current')
would then look like
file = repo.repovfs('bookmarks.current')
I'd say repo.vfs is ok.
BTW, has anyone thought about renaming __call__ on the opener class to
open? After all, vfs is not just an "opener" any more...
So perhaps we could then write code like
file = repo.vfs.open('bookmarks.current')
> wopener -> workingvfs
> sopener -> storevfs
These are ok (if we have to keep the "v" in "vfs").
More information about the Mercurial-devel
mailing list