[PATCH 5 of 8] obscache: add a cache for 1/2 of the "obsolete" property
Pierre-Yves David
pierre-yves.david at ens-lyon.org
Fri May 19 18:15:25 EDT 2017
On 05/19/2017 11:53 PM, Augie Fackler wrote:
> On Fri, May 19, 2017 at 04:28:04PM +0200, Pierre-Yves David wrote:
>> # HG changeset patch
>> # User Pierre-Yves David <pierre-yves.david at octobus.net>
>> # Date 1495197986 -7200
>> # Fri May 19 14:46:26 2017 +0200
>> # Node ID c2b1c81b3c4cba8cc21b1a1b92f4e34e6aa1807a
>> # Parent b5c984cd0640255b94f22d56a4bfe398b2c5de2e
>> # EXP-Topic obscache
>> # Available At https://www.mercurial-scm.org/repo/users/marmoute/mercurial/
>> # hg pull https://www.mercurial-scm.org/repo/users/marmoute/mercurial/ -r c2b1c81b3c4c
>> obscache: add a cache for 1/2 of the "obsolete" property
>
> So, can you point me to other (upcoming) concrete subclasses of
> dualsourcecache, or is this the only one?
There are current a second user of this abstract class in evolve. It is
used for obsdiscovery[1]. And I expect to we'll experiment with more of
this class of cache in the near future.
[1]
https://www.mercurial-scm.org/repo/evolve/file/71d242e0fc1a/hgext3rd/evolve/obsdiscovery.py#l440
The logic in the cache is easy to screw up and the end result is really
need to use (implement save/load/reset/update(revs, obs)). Having a
class ready to use is -really- handy.
In addition, there are final stage of skip-obsstore optimization that
requires some rework and collaboration in core something hard to access
from an extension.
So, having this intermediate abstract class is a corner-stone of the
current contribution. (most of work in evolve 6.2 is actually about
extracting and reusing this logic)
> Also, could we put these big new classes in obscache.py or some other
> new file? I'm wary of adding more code to the already-1200-lines
> obsolete.py, and since these are coming from evolve I'm hoping that
> they're still easily separable from obsolete.py...
This crossed my mind when adding it. However, there are significant
improvement to that class arriving soon. These improvement will need to
access (and refactor) some lower logic around reading markers and al. I
think it is wiser to wait for the dust to settle after these upgrade and
cut where this is
(the version in evolve access some "_private" method and duplicates some
code)
Cheers,
--
Pierre-Yves David
More information about the Mercurial-devel
mailing list