making memctx more generally useful

[Christian Ebert]

* Kevin Bullock on Saturday, January 05, 2013 at 13:26:17 -0600
> [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.


The keyword extension already does this for record and amend.

-- 
theatre - books - texts - movies
Black Trash Productions at home: http://www.blacktrash.org
Black Trash Productions on Facebook:
http://www.facebook.com/blacktrashproductions