Gregory Szorc <gregory.sz...@gmail.com> writes: > On Sun, Jul 9, 2017 at 10:52 AM, Boris Feld <boris.f...@octobus.net> wrote: > >> # HG changeset patch >> # User Boris Feld <boris.f...@octobus.net> >> # Date 1499458441 -7200 >> # Fri Jul 07 22:14:01 2017 +0200 >> # Node ID 6edb62505c697329de034c2fdc47befd5896f31f >> # Parent 89796a25d4bb91fb418ad3e70faad2c586902ffb >> # EXP-Topic obs-cache >> cache: introduce an abstract class for cache we can upgrade incrementally >> >> Right now each class implements their own mechanism for validation, and >> update. We start introducing abstract class to ultimately allow more >> unification of the cache code. >> >> The end goal of this series is to introduce a cache for some obsolescence >> property, not to actually implement the cache. However, taking advantage of >> adding a new cache to introduce the abstract class seems like a win. >> > > I don't like saying this, but given the amount of discussion these patches > generated the last time they were proposed and given the proximity to the > code freeze, I doubt these will land in 4.3. > > Would you be willing to voluntarily withdrawal them from consideration for > 4.3? Or if there are less contentious patches/functionality that you would > like to land in 4.3, would you be willing to pair down the series to the > simpler/less-contentious patches so we can focus on 4.3?
I'm also fine to wait for 4.3 since the freeze is a week away. Taking this in another direction, I have long wanted a generic cache object as an extension author (both in remotenames and hg-git; but other extensions as well). So, having a refactored cache class that both tags and branches could use would indeed be a win (then maybe finding an extension that could use it as well). The obs part of this discussion can wait until after the freeze.
signature.asc
Description: PGP signature
_______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
