making memctx more generally useful

[Matt Mackall]

On Sat, 2013-01-05 at 00:47 -0600, Steve Borho wrote:
> On Fri, Jan 4, 2013 at 10:31 PM, Steve Borho <steve at borho.org> wrote:
> 
> >
> >
> >
> > On Fri, Jan 4, 2013 at 10:10 PM, Kevin Bullock <
> > kbullock+mercurial at ringworld.org> wrote:
> >
> >> On 4 Jan 2013, at 5:22 PM, David Schleimer wrote:
> >>
> >> >>> When this was discussed on IRC; someone (I sometimes wish we kept IRC
> >> >>> logs) mentioned they had a patch series that accomplished most of
> >> >>> option #2.  Now would be a good time to post them, since it seems to
> >> >>> be recognized as the best way to start this process.
> >> >
> >> > I've gone a fair way down the route of refactoring the
> >> localrepo.commit() logic into smaller methods on the working context while
> >> trying to make graft faster in an mpm-acceptable way.  I thought I would
> >> have time to pull out the refactoring bits of that series, pull a little
> >> more into the working context so that it's a complete series, and send it
> >> this week.  Unfortunately, one of our repos got wiped out over the break
> >> and I haven't been able to put as much time into it as I expected.  I
> >> should be able to send a patch series worth discussing on Monday.
> >> >
> >> >>> - Moving commit logic outside local repo would be a net win
> >> >>> - I'm not sure #2 solve alone the amend problem. We needs to:
> >> >>>  1) copy "." into a memctx,
> >> >>>  2) apply commit logic with content from the wctx to our memctx,
> >> >>>
> >> >>> A mix of #2 and #3 is probably the way to
> >> >
> >> > I'm splitting localrepo.commit() because it's easier to pull into the
> >> working context piecewise.  I think we will probably want to have memctx
> >> extend workingctx so that they can share a lot of the munging logic
> >> localrepo.commit() currently does.
> >>
> >> At that rate, it might make more sense to extract a superclass for both
> >> workingctx and memctx.
> >>
> >
> > Speaking for my own requirements; what I really need is a workingctx that
> > can use a patch.filestore to provide data for just a subset of files.  I
> > don't really need a memctx at all.  Looking at things from that angle, I
> > may be able to get the behavior I need by simply modifying the workingctx
> > class for just the scope of the commit command.  If I was careful, this
> > wouldn't interfere with any of the extensions that wrap the localrepo
> > commit methods.
> >
> 
> I went ahead and tried this approach and it is almost working.  See
> attached extension (only 72 lines).
> 
> The only problem I have is that the dirstate, after a partial commit,
> thinks the files are un-modified until I 'touch' them to change their
> mtime.  Only then does hg realize the working copy contents are different
> from the contents that were checked in.   How does the memctx avoid this
> issue?

See here:

http://www.selenic.com/hg/file/2c1276825e93/mercurial/commands.py#l3733
http://www.selenic.com/hg/file/2c1276825e93/mercurial/commands.py#l3899
http://www.selenic.com/hg/file/2c1276825e93/mercurial/context.py#l1305

The answer to "should committable context objects have a commit()
method" seems to be "yes".

-- 
Mathematics is the supreme nostalgia of our time.