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

Matt Mackall mpm at selenic.com
Sun Jun 17 15:47:16 CDT 2012


On Sun, 2012-06-17 at 17:49 +0900, FUJIWARA Katsunori wrote:
> At Sun, 17 Jun 2012 01:16:01 -0500,
> Matt Mackall wrote:
> > 
> > On Sat, 2012-06-16 at 03:00 +0900, FUJIWARA Katsunori wrote:
> > > At Fri, 15 Jun 2012 10:31:45 -0500,
> > > Matt Mackall wrote:
> 
> > > > 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
> > > > ...
> > > 
> > > I understand that both "add a couple methods" and "convert some users"
> > > mean "don't replace whole of code at once", am I right ?
> > 
> > It means I want to see the "small, interesting implementation bits"
> > separated from the "large, boring, trivial conversions".
> > 
> > > Would you like the steps below ?
> > > 
> > >     1. pick some code path up
> > >     2. check direct file API invocations in the path
> > >     3. add just "a couple of" methods to current "opener" to invoke
> > >        such APIs, if needed
> > >     4. make codes in the path use methods of "opener"
> > >     5. repeat from (3) to (4) for the path
> > >     6. repeat from (1) to (5) for all paths
> > >     5. create patch for each pairs of (3) and (4)
> > 
> > Please do a small amount of initial work, stop, and send a few patches.
> > Much smaller than the current batch.
> 
> OK, I'll send small patch series to confirm working direction.
> 
> 
> > > BTW:
> > > 
> > > > "Rename opener to vfs"
> > > 
> > > Should I rename both name of class and referring variables of "opener"
> > > to "vfs"?  or only name of class ?
> > 
> > Well, we'll probably want to do both eventually. I think since we'll be
> > adding a bunch of new callers to repo.<foo>.<someop>, we want to do
> > rename the variables first, so we don't have to go back and change even
> > more things later.
> 
> Sorry, I can't understand below sentence because of my poor English.
>
> > so we don't have to go back and change even more things later.
> 
> But, I imagine the way to minimize changes in transition period like
> as below. How about this ?
> 
>     1. add "vfs" like field(s) to objects referring openers, and make
>        them referring openers too, at first
> 
>     2. use (or replace) "vfs" field instead of "opener" field in each
>        small patch works
> 
>     3. finally, remove "opener" fields, when all of referring to them
>        are replaced by ones to "vfs"

That's a fine approach. What's not good is to introduce usage like

  repo.wopener.stat(f)

that we know we'll later want to change.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list