[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mercurial-devel
Subject:    Re: [PATCH 1 of 7] fncache: remove the rewriting logic
From:       Durham Goode <durham () fb ! com>
Date:       2014-03-31 17:29:25
Message-ID: CF5EF28D.DD19%durham () fb ! com
[Download RAW message or body]

On 3/26/14 12:26 PM, "Matt Mackall" <mpm@selenic.com> wrote:

>On Mon, 2014-03-24 at 19:33 -0700, Durham Goode wrote:
>> # HG changeset patch
>> # User Durham Goode <durham@fb.com>
>> # Date 1395700307 25200
>> #      Mon Mar 24 15:31:47 2014 -0700
>> # Node ID ab3be74e8022c31b7c95975fb09b3602ed7775d8
>> # Parent  3879ac3858ffd9bb46e19fcc3a2b31d7bb2b54c5
>> fncache: remove the rewriting logic
>> 
>> The fncache could rewrite itself during a read operation if it noticed
>>any
>> entries that were no longer on disk. This was problematic because it
>>caused
>> Mercurial to perform write operations outside the scope of a lock or
>> transaction, which could interefere with any other pending writes.
>> 
>> This will be replaced in a future patch by logic that cleans up the
>>fncache
>> as files are deleted during strips.
>
>From an ordering-of-patches standpoint, this looks problematic. I'd like
>to take this off your plate, but since I have questions about the
>subsequent patches, that would leave us in a state where there's nothing
>that rewrites the fncache at all, right?

You are correct.  Getting rid of this first made future patches cleaner
and more correct (since this logic doesn't play nice when transactions are
introduced). Having junk data in the fncache doesn't seem to be an issue
though, since it's lazily cleaned up and only in certain scenarios.

_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@selenic.com
http://selenic.com/mailman/listinfo/mercurial-devel
[prev in list] [next in list] [prev in thread] [next in thread]