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

Augie Fackler raf at durin42.com
Tue Jun 13 10:13:42 EDT 2017


On Sun, Jun 11, 2017 at 03:30:26PM -0700, Sean Farley wrote:
> Pierre-Yves David <pierre-yves.david at ens-lyon.org> writes:
>
> > On 06/11/2017 10:01 AM, Yuya Nishihara wrote:
> >> On Fri, 9 Jun 2017 10:59:32 +0100, Pierre-Yves David 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.
> >>
> >> Yeah, the idea sounds great. I'm not sure if inheritance is the best option,
> >> but that's probably the easiest choice to move things forward. Perhaps a
> >> better (and harder) alternative is to split storage layer from localrepository
> >> and switch it by immutable or not.
> >
> > I agree with the above. Using inheritance is good first step. It allow
> > to introduce all the semantic changes we wants without breaking the API.
> > We can look into changing the API are a second step. But having two
> > steps will makes this much simpler.
>
> I have a slightly different approach (and maybe Greg and I should sync
> up) that moves most of the access pattern to context objects.

That sounds promising. Could you and Greg sync at some point and let
us know how that works out?

> My end
> goal is for (e.g. extension authors) most operations you want will be
> through a context. This would make localrepo mostly (I haven't finished
> so can't say yet) read-only.
>
> More concretely, my first series is about moving localrepo.dirstate ->
> workingctx. Then moving localrepo.wvfs -> workingctx; etc.



> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


More information about the Mercurial-devel mailing list