[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