[PATCH 3 of 3 V3] memctx: allow the memlightctx thats reusing the manifest node
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