[PATCH 1 of 3 RFC] context: move dirstate to workingctx

[Sean Farley]

Jun Wu <quark at fb.com> writes:

> While this might work in a short term to work with merge.update, I think
> dirstate is special and complex enough to be detached from a ctx (ex.
> memctx) object, except for wctx.
>
> Ideally, I think the main wctx/mctx API is just __setitem__(path, fctx):
>
>   # change content
>   ctx[path] = overlayfilectx(ctx[path], datafunc=lambda: newdata)
>
>   # change exec or symlink
>   ctx[path] = overlayfilectx(ctx[path], flags='xl')
>
>   # change copy information
>   ctx[path] = overlayfilectx(ctx[path], copied=(path, filenode))
>
>   # remove a file
>   ctx[path] = None
>
> Since ctx knows a manifest, the above interface is enough for a mctx to
> figure out what's added, modified, removed, copied at commit time. wctx
> could use dirstate as an implementation detail to deal with "copied"
> change. The benefit of "writing a fctx" allows us to have LFS fast path for
> free.
>
> For an extension developer's point of view, I think it's more friendly to
> make the following just work:
>
>   mctx = memctx()
>   mctx['newfile'] = memfctx(data='new file content')
>   mctx['cheap-copy-a-large-file'] = ctx['a-large-file']
>   mctx['deleteme'] = None
>   mctx.commit()
>
> without requiring a developer to figure out dirstate manually like:
>
>   mctx.dirstate.add('newfile')
>   ...

Yeah, that's pretty much what I had in mind. I guess I had imagined this
RFC direction to be more-or-less a cleanup that would end with dirstate
becoming a private member (then later doing as you outline here)
-------------- 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/20170531/86d0c107/attachment.sig>