[PATCH 3 of 3 V3] memctx: allow the memlightctx thats reusing the manifest node

Augie Fackler raf at durin42.com
Fri Dec 2 17:11:41 EST 2016


On Fri, Nov 25, 2016 at 12:15:57PM +0000, Mateusz Kwapich wrote:
> I like the relocate idea. It would be an useful abstractions - we have a
> lot of things that are rewriting one commit at a time.

These patches are queued with the rename of the class performed. Thanks!

>
> Excerpts from Jun Wu's message of 2016-11-22 22:18:59 +0000:
> > Excerpts from Augie Fackler's message of 2016-11-21 18:26:16 -0500:
> > > Also, could histedit be updated to use this for 'mess' actions
> > > perhaps? Probably not easy, but if it is I'd love to see an in-tree
> > > client of this class. Can you take a look?
> >
> > It does not work if "mess" happens after other csets creating new manifests.
> >
> > Instead of making it a special for histedit. I'm always more interested in
> > a general purpose lower-level function doing some kind of "rebase" in core,
> > that smartly deals with this case and handles bookmark and dirstate parent
> > movements (and obsmarker creation) automatically.
> >
> > There are currently multiple places reinventing the logic over and over:
> >   - absorb / collate
> >   - rebase
> >   - histedit
> >   - evolve
> >
> > And once we have this API in core, we can migrate the above commands to use
> > it.
> >
> > I'm thinking about something like:
> >
> >   relocate(origctx, newparents, fileoverrides, metaoverrides, obsoleted,
> >            transaction)
> >   # origctx: context
> >   # newparents: [node]
> >   # fileoverrides: abstract dict, keys: path, value: (content, mode, renamed)
> >   # metaoverrides: dict with defined set of keys. to override metadata like
> >   #                commit message etc.
> >   # obsoleted: bool, could also be a non-bool to provide more metadata
> >
> > Then relocate will choose what *ctx to use internally. For absorb,
> > metaoverrides is empty, for metaedit, fileoverrides is empty. For rebase,
> > both are empty. For histedit, depends.
> >
> > Two things I'd like to make sure they are considered while developing the
> > API:
> >
> >   1. Giant files friendly - if we need to commit two giant files, we don't
> >      need to keep both of them in memory. "fileoverrides" being an abstract
> >      dict should solve this.
> >   2. Commit hooks friendly - if any commit hook is requiring a working copy,
> >      fallback to the slow path that writs the disk. (this could be the most
> >      complex part of the implementation, but I guess crecord-alike already
> >      has similar things). We also need to have ways to mark a commit hook as
> >      "do not require on-disk working copy" - could be a config option, or
> >      checking some magic string in the hook itself.
> >
> > If we decide to go this way, I could help start some more formal discussion
> > (a plan page or so) - hopefully we can collect enough corner cases that
> > need support, have a final decision about the API soon.
> >
> > CC smf because it could be related to your memctx work.
>
> --


More information about the Mercurial-devel mailing list