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

Gregory Szorc gregory.szorc at gmail.com
Wed Jun 14 00:18:11 EDT 2017


On Sun, Jun 11, 2017 at 3:30 PM, Sean Farley <sean at farley.io> 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. 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.
>

This sounds similar to what I want to do! I want to have a read-only base
class then have context managers that return either a derived class or a
special type that exposes operations to mutate the repo. I didn't get
around to it in this series because that work involves a lot of BC breakage
and I specifically wanted to avoid major BC breakage as part of the initial
refactor in order to maximize the chances of the idea being accepted.

I was also toying with the idea of splitting up functionality into multiple
classes and using multiple inheritance on the repo type. Alternatively, we
could obtain instances of these domain-specific types via context managers.
I haven't thought as much about this aspect because it was too BC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170613/3d715254/attachment.html>


More information about the Mercurial-devel mailing list