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

[Gregory Szorc]

On Tue, Nov 22, 2016 at 2:18 PM, Jun Wu <quark at fb.com> wrote:

> 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.
>
>
This is a good idea. And it has been discussed before! Often in the context
of https://www.mercurial-scm.org/wiki/PlanHistoryRewritePlan.

I once showed Pierre-Yves some code (
https://hg.mozilla.org/hgcustom/version-control-tools/file/6298a2195598/pylib/mozhg/mozhg/rewrite.py)
Mozilla wrote to do generic changeset rewriting. He was receptive to
introducing a rewrite.py or rewriting.py in the core project and
consolidating low-level history rewriting code there. Whether Mozilla's
code could be used - probably not, as it was designed for a very narrow
focus.


> 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.
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20161125/3a8c68f5/attachment.html>