making memctx more generally useful

[Steve Borho]

On Thu, Jan 3, 2013 at 2:30 AM, Christian Ebert <blacktrash at gmx.net> wrote:

> * Steve Borho on Wednesday, January 02, 2013 at 14:31:01 -0600
> > I am in the middle of adding a record-like hunk selection feature to the
> > TortoiseHg commit tool; using a patch based memctx to avoid having to
> > repeatedly re-write working copy files and potentially bungling the
> > dirstate.
> >
> > A problem that I have encountered (and based on a quick chat on IRC I am
> > not the first) is that memctx.commit() directly calls into
> > localrepo.commitctx() bypassing all the logic in localrepo.commit() which
> > knows about subrepos, bookmarks, merge state, hooks, etc.
> >
> > For the short term; I am duplicating the functionality of
> > localrepo.commit() within my partial commit function, but it seems like
> > there is a lot of room for improvement here to make the
> localrepo.commit()
> > functionality more reachable.
> >
> > Option #1 (minimal)
> >
> > add an optional getcctxfn=context.workingctx argument to
> localrepo.commit()
> > so callers can inject their own commit context callback; using the
> changes
> > list and other arguments that localrepo.commit() discovers
> >
> > Option #2
> >
> > Move localrepo.commit() functionality into workingctx, make memctx derive
> > from workingctx
> >
> > Option #3
> >
> > Split localrepo.commit() into multiple functions which can be called a la
> > carte
> >
> > Preferences?  Other options?
>
> I always wanted to find a way to use memctx in the keyword
> extension but could not and still cannot wrap my head around the
> memctx concept.
>
> Performance-wise it would probably most useful for update and
> friends, but there I don't see how it could work because we need
> to get the last change per file - a bit like hg log -l1 file. But
> I might be utterly wrong in my understanding of memctx.
>
> For commit I am quite certain that there must be a way to use it,
> and perhaps even to make keyword cooperate with largefiles; see:
> http://bz.selenic.com/show_bug.cgi?id=3550


Thanks for bringing this bug to my attention.  It's pretty clear that my
partial commit function will break largefiles as well; so change selection
will have to be disabled if largefiles is enabled (or any other extension
which wraps localrepo.commit()).

-- 
Steve Borho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130103/2f8943be/attachment.html>