[PATCH 2 of 2] convert: execute merges in-memory (issue5076)

[Tony Tung]

On Feb 23, 2016, at 1:45 PM, Sean Farley <sean at farley.io> wrote:

>>> On Feb 23, 2016, at 1:13 PM, Sean Farley <sean at farley.io> wrote:
>>> 
>>> 
>>> Augie Fackler <raf at durin42.com> writes:
>>> 
>>>>> On Tue, Feb 23, 2016 at 12:14:00AM -0800, Tony Tung wrote:
>>>>> # HG changeset patch
>>>>> # User Tony Tung <tonytung at merly.org>
>>>>> # Date 1456215137 28800
>>>>> #      Tue Feb 23 00:12:17 2016 -0800
>>>>> # Node ID b7f61d7438ba1aed06afa1a53a2b5fda8bdc225f
>>>>> # Parent  cbc605f28b61cc469e21186982d0569bf94f7d2a
>>>>> convert: execute merges in-memory (issue5076)
>>>> 
>>>> I think this makes sense. Sean, you've done in-memory merge stuff,
>>>> does this look sensible at least for convert to you?
>>> 
>>> My spider senses did go off with the subject line but I don't really see
>>> what is changing here. There's a change in the method signature and a
>>> check for it later but everything else with the merge machinery
>>> (workingctx and its interaction with wwrite) remains untouched. Perhaps
>>> the 'hg convert' code path takes a different route? I'm guessing Tony is
>>> referring to merging the manifest (and not the other machinery I
>>> mentioned)?
>>> 
>>> If so, then it seems this 'inmemoryonly' argument might be used (perhaps
>>> by me) later for a first attempt of a pure in-memory merge.
>> 
>> The hg convert path will not check for dirty subrepos because the working copy remains untouched throughout the entire conversion process.
> 
> Ok, so this has nothing to do with an actual in-memory merge. Just
> converting without touching the working directory.

I assume this is in reference to a mercurial-specific concept, because otherwise I am very confused. :)

Thanks,
Tony