[PATCH 1 of 8 RFC] vfs: replace invocation of file APIs of os module by ones via vfs

Matt Mackall mpm at selenic.com
Fri Jun 15 10:31:45 CDT 2012


On Fri, 2012-06-15 at 23:45 +0900, FUJIWARA Katsunori wrote:
> # HG changeset patch
> # User FUJIWARA Katsunori <foozy at lares.dti.ne.jp>
> # Date 1339768793 -32400
> # Node ID a14b63be9a04e7fac445fea69bbaf840ca3f4063
> # Parent  622aa57a90b1d1f09b3204458b087de12ce2de82
> vfs: replace invocation of file APIs of os module by ones via vfs

You seem to have missed the importance of step 1:

"Rename opener to vfs"
http://mercurial.selenic.com/wiki/WindowsUTF8Plan#Steps

The whole point of this exercise is to have one (or just a few) central
objects we route all our file operations through that are attached to
repository objects so that repository objects can easily switch their
modes as needed. Conveniently, we have something very much like that
already: it's called an opener. It's even beginning to grow some of
these sorts of methods.

In particular, we'll want to take one of these objects, wopener, and
switch it to UTF-8 mode.. while leaving the other two in native mode.
Which means we need to be calling methods at a high enough level that we
know which part of the repository we're operating on...

>     1. replace all invocations of above functions "os.XXXX()" by
>         "util.vfs().XXXX()" mechanically: or adding "vfs()." in
>         util.py itself

...thus creating vfs objects on the fly with util.vfs() doesn't get us
any closer to having centralized control on them.  

Also, this patch is quite big. It took me a while to locate the only
real interesting bit: the definition of vfs. I'd rather see:

1. rename the object
2. add a couple methods
3. convert some users
4. add some methods
5. convert some users
...

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list