[PATCH 1 of 6 RFC] localrepo: establish a base class for an immutable local repository

[Gregory Szorc]

On Fri, Jun 9, 2017 at 2:59 AM, Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

>
>
> On 06/09/2017 07:36 AM, Gregory Szorc wrote:
>
>> # HG changeset patch
>> # User Gregory Szorc <gregory.szorc at gmail.com>
>> # Date 1496977416 25200
>> #      Thu Jun 08 20:03:36 2017 -0700
>> # Node ID dfe0db942bbf860968b19fd8579865790d78d5e8
>> # Parent  e583b786ffba99cb775cf9d3a126cf50db74f85a
>> localrepo: establish a base class for an immutable local repository
>>
>
> I like the general idea and direction of this series. Moving toward more
> guarantee of having a consistent view of the repository is great.
>

Obviously the current repo store design can't be fully consistent because
there are race conditions between process A opening files and process B
mutating them. However, my utopia end state is we devise a storage model
(either based completely on append-only data structures or on
file/directory based "generations" for data that isn't append-only) and
readers can read a single file denoting current offsets/generations to get
an atomic and consistent view of a repo.


>
> Currently, localrepository has a number of properties that are cached
>> based on things changing. For attributes behind @repofilecache or
>> @storecache, we perform a stat() on every attribute access.
>>
>
> Actually, according to the code, we do not do performa that "stat()" check
> for every attribute access.
>

>
> https://www.mercurial-scm.org/repo/hg/file/326c0e2c1a1d/merc
> urial/scmutil.py#l855
>
> What the filecache does it reusing a previously loaded object if the
> repository caches has been invalidated (so the attribute is missing) but
> underlying file did not changed. It is convoluted, but the "stat()" is
> rarely issued and  we should not see the alarming performance impact
> mentioned here.
>

Ugh. Can't believe I missed that. But it does prove my point that caching
is hard and is best avoided :)


>
> That said, none of the above has impact on Greg code and we should still
> move toward Greg idea.
>
> (I did not had time to check the rest of the series or the code more
> through-fully yet.)
>
> Cheers
>
> --
> Pierre-Yves David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170609/38e04e8c/attachment.html>