[PATCH 1 of 8] largefiles: replace "_isXXXXing" attributes with "_lfautocommit"

FUJIWARA Katsunori foozy at lares.dti.ne.jp
Mon Oct 6 10:24:59 CDT 2014


At Thu, 25 Sep 2014 00:43:23 +0200,
Mads Kiilerich wrote:
> 
> On 09/24/2014 03:11 PM, FUJIWARA Katsunori wrote:
>
> > On Mon, 22 Sep 2014 11:14:56 +0200, Mads Kiilerich <mads at kiilerich.com> wrote:

> >   Even though these hooks can't see appropriate largefiles now too :-),
> >   deep hooking can fix this problem.
> 
> If we really want deep hooking then I would consider experimenting with
> hooking in to the vfs layer, updating standin files every time they are
> read or walked and are out of date, and propagating their value every
> time they are written.

"vfs layer hooking" looked good and I thought about feasibility of
it. But I finally concluded that it causes performance problem at
getting largefiles from remote. For example, in the case of "hg
update":

  - now:

    largefiles are gotten all together from the remote by
    "updatelfiles" at the end of "merge.update".

    in this case, network channel is opened only once for each "hg
    update"

  - after "vfs layer hooking":

    each largefiles are gotten separately at the end of "vfs.write"
    for standins.

    in this case, network channel is opened for each largefiles while
    "hg update" (or a kind of batching of getting largefiles while "hg
    update" is needed)


> > What do you think about these points ?
> 
> I think they are valid. There is no perfect solution ... and probably
> not even a good one. But I think we should reconsider whether the
> current approach of violating all layers and add hacks everywhere is the
> best solution.

Then, I've hit upon another approach to solve the issue without adding
hook points into Mercurial core (like "automatedcommit" in this series).

I'll send the revised series soon !


----------------------------------------------------------------------
[FUJIWARA Katsunori]                             foozy at lares.dti.ne.jp


More information about the Mercurial-devel mailing list