[PATCH] changelog: load pending file directly

[Gregory Szorc]

On Sat, May 13, 2017 at 5:11 PM, Jun Wu <quark at fb.com> wrote:

> Looks good to me. I like the clean up.
>
> Excerpts from Gregory Szorc's message of 2017-05-13 16:29:50 -0700:
> > [...]
> >      @storecache('00changelog.i')
>
> storecache needs to include '00changelog.i.a'. But that belongs to another
> patch.
>

I thought about this when I wrote the patch. Semantically, yes @storecache
should include 00changelog.i.a. However, I don't think it actually needs it
because:

* 00changelog.i.a should be immutable for the lifetime of its existence
* when the transaction closes successfully, 00changelog.i is updated,
invalidating the cache
* when the transaction aborts, file cache is purged via
repo.invalidate(clearfilecache=True) and the transaction context is over,
so the next .changelog will load 00changelog.i

There's also the issue of a reader invalidating its .changelog by an
independent writer starting a transaction. That feels sub-optimal.

FWIW, I had a series a year or so ago where I added a context manager that
when active basically said "I am a read-only operation." It aggressively
cached some things, leading to significant perf wins for some operations.
If I had infinite time, I'd hack on that a bit more and refactor the
localrepo class so you needed to obtain a specific class/type representing
a mutable repository, probably via a context manager based API that also
handled locks and transactions. If done right, most consumers could assume
a read-only repo and aggressively cache by default (rather than today,
where we check for freshness on e.g. every .changelog attribute access.
Related to this idea, I want to add a context manager API to the localrepo
class to indicate intended access patterns. For example, the optimization
strategy for reading revlogs varies significantly depending on if you are
reading forward or reverse and whether you are accessing all revisions or a
subset. If we had a hint of the anticipated access pattern, we could
optimize I/O and caching patterns appropriately. Unlike a
"read-only/mutable repo context manager," a perf-centric "anticipated
access patterns context manager" is something I may do in 4.3.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170513/16d7d85f/attachment.html>