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

[Sean Farley]

Gregory Szorc <gregory.szorc at gmail.com> writes:

> 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.

Ah, perhaps there is a naming clash here. I meant mercurial/context.py
not python's context manager. It's an idea I've been circling since I
started memctx (and that Jun brought up recently due to his LFS work)
merge years ago; not for read-only stuff (which you are working on) but
for data access. Let me use a code example to help illustrate this:

# make a new commit
m = memctx(...)
m['file_foo'] = my_new_data() # returns a read-only object memfilectx
m.commit()

# write something to disk
ctx = repo[None] # workingctx
ctx['file_foo'] = some_data() # returns a read-only workingfilectx object
# nothing to commit here

There are a lot of questions to answer still but I hope this is a more
clear picture of what I'm thinking.

P.S. we both live < 2 miles from each other; perhaps I should schedule
another weekend hackday?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170613/8558751e/attachment.sig>