[PATCH 3 of 5] localrepo: add memcommit() to commit without working directory

[Matt Mackall]

On Tue, 2008-06-03 at 23:15 +0200, Patrick Mézard wrote:
> > The latter two parts could actually
> > be done with callbacks, so that we don't have to have entire changesets
> > in memory.
> 
> Which means the context object is not really a context object but something different again.

No. A "context" is "the state of a collection of files". In other words,
it's exactly what "commit" stores. If I pass a context c to commit, it
wants to be able to get a list of changed files (eg c.files()) and their
contents (c[f].data()) and their flags.

> I am not really convinced by the benefits of this approach:
> - Contexts are complicated beasts. I don't think we can subclass them,
> and duck-typing may not be possible because of the status() methods
> (removed(), deleted(), ...) which are not easy to implement on remote
> sources.

Why can't we subclass them? It worked fine for workingctx.
By the time we're calling memcommit, we presumably have all the relevant
data.

> - This file abstraction will be useful beyond the convert extension, I
> am thinking of all the wiki engines/db bindings out there. So, in my
> opinion, the simpler the better, especially from the caller point of
> view.
> - You imply we can pass a context to localrepo.commit(). Right now, I
> don't even know how to refactor it correctly to take filectx like
> objects, there are too many code paths and magical behaviours relying
> on the dirstate. As I said, I don't like copy/pasting code but here I
> really prefer to offer a clean, boring "commit()" version taking the
> filectx() and the commit information as separate parameters.

Commit is currently hairy because it has to pay attention to the
dirstate sometimes (normal commits) and not others (rawcommits).
The point of going to contexts is that commit will no longer know about
the dirstate. Everything it needs to know about files, it will have to
get through the context. Thus, normal commits and rawcommits and
memcommits will all look the same to it.

> For a moment, I saw what you meant and admit mimicking contexts is
> seducing. But it looks impractical to me and miss the point. What I
> would keep is fileobject should be compatible with filectx objects. I
> am not sure it's useful to wrap the commit information in an object, I
> don't really see what it brings.

Convert is already doing that with "class commit", which when combined
with your fileobjs is basically a context already.

-- 
Mathematics is the supreme nostalgia of our time.