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

Sean Farley sean at farley.io
Thu Nov 17 17:17:22 EST 2016


Jun Wu <quark at fb.com> writes:

> Excerpts from Sean Farley's message of 2016-11-17 13:41:54 -0800:
>> Jun Wu <quark at fb.com> writes:
>> 
>> > Per discussion offline, I think this (a new class) approach is the cleanest
>> > and safest approach to reuse manifest nodes.
>> >
>> > "absorb" has an "overlaycontext" which takes an "original" context, but
>> > overrides some file contents. In the future we may want to have such
>> > overlaycontext, while the "memlightctx" is a special case where you don't
>> > override any file contents. Note: that should not require a resend of this
>> > patch to implement such overlaycontext feature right now.
>> 
>> Why can't we refactor memctx? I was planning on removing committablectx
>> in the future and just use memctx to build a commit (and even merge).
>
> Then you will either:
>
>   a) worry about the "consistency" of "files" and "manifestnode" - people
>      (ex. new programmer) passing inconsistent "files" and "manifestnode"
>      will be able to add buggy content to the repo.
>
> or:
>
>   b) have perf issues - if you calculate "files" from "manifestnode" and
>      its parent - it's slower than just getting "files" from the changelog.
>
> Therefore a new class taking a "changelog node" makes perfect sense. It
> can generate "manifestnode" and "files" efficiently and have no perf or
> consistency issues.

I guess that's alright for now. I'll think about my future refactorings
later.


More information about the Mercurial-devel mailing list