Fwd: making memctx more generally useful
Kevin Bullock
kbullock+mercurial at ringworld.org
Sat Jan 5 19:26:17 UTC 2013
[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
More information about the Mercurial-devel
mailing list