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


The way I think of memctx is that it is an arrangement of callback methods
that allow you add a new changeset (commit) without touching a workingctx.
 Basically the workingctx interfaces that localrepo.commitctx() calls have
been abstracted out in the memctx so that you can insert your own
functionality.  There isn't a lot to it.  You create a memctx with a list
of files and commit data (message, user, date, extras), then call
memctx.commit() which calls localrepo.commitctx().  As the repo commits
each file in your list of files, it makes a callback to your code for the
file contents, exec and link flags, and copy/rename status.  And you can
return all of that data from tempfiles, dictionaries, or wherever you like.

I don't think it is applicable to update, though.

-- 
Steve Borho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20130103/0e81c21f/attachment-0002.html>