Fwd: making memctx more generally useful

[Kevin Bullock]

[I'm assuming this wasn't intended for my eyes only.]

Begin forwarded message:

> From: Steve Borho <steve at borho.org>
> Subject: Re: making memctx more generally useful
> Date: 5 January 2013 1:56:28 AM CST
> To: Kevin Bullock <kbullock+mercurial at ringworld.org>
> 
> On Sat, Jan 5, 2013 at 12:47 AM, Steve Borho <steve at borho.org> 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?
>  
> Apologies for responding to my own posts, but I have found that adding this snippet post-commit resolves my problem:
> 
> +            wlock = repo.wlock()
> +            try:
> +                for f in store.keys:
> +                    repo.dirstate.normallookup(f)
> +            finally:
> +                wlock.release()
> 
> I think I'm good to go. This gives me my partial commits without duplicating any hg code or adversely affecting extensions like largefiles which wrap localrepo.commit().
> 
> FWIW; I think the record extension could also use this approach.
> 
> -- 
> Steve Borho