[PATCH 4 of 8 RFC] update: when guarding, check merges for conflicts

[Laurens Holst]

Op 21-12-2011 23:30, Matt Mackall schreef:
> On Wed, 2011-12-21 at 23:25 +0100, Laurens Holst wrote:
>> Op 21-12-2011 22:15, Matt Mackall schreef:
>>> On Wed, 2011-12-21 at 20:45 +0100, Laurens Holst wrote:
>>>> # HG changeset patch
>>>> # User Laurens Holst<laurens.hg at grauw.nl>
>>>> # Date 1324433649 -3600
>>>> # Node ID 64831bdb5dddf916d5378ace8965a2b2d619d5ee
>>>> # Parent  0fe9df236d957abc682c75d71910fa041c7390fd
>>>> update: when guarding, check merges for conflicts
>>>>
>>>> If a file is changed both in the working copy and in one of the updated
>>>> changesets, during the guarding phase it will attempt to merge the two using
>>>> simplemerge to see if there are conflicts. If none of the mutually changed files
>>>> have conflicts, the guard will allow the update to proceed.
>>>>
>>>> diff -r 0fe9df236d95 -r 64831bdb5ddd mercurial/merge.py
>>>> --- a/mercurial/merge.py	Wed Dec 21 04:04:52 2011 +0100
>>>> +++ b/mercurial/merge.py	Wed Dec 21 03:14:09 2011 +0100
>>> [...]
>>>> +            # test-merge mutually modified files to see if there are conflicts
>>>> +            m3 = simplemerge.Merge3Text(fca.data(), fcl.data(), fco.data())
>>> Big layering violation here. The merge tool configured for the given
>>> file may deal with this perfectly, or refuse to work at all.
>>>
>> Mmm yes there is an assumption that a merge tool essentially merges
>> equally smart or smarter. I wrote a comment about that in the commit
>> message of patch 8.
> No, the problem is bigger than that. "Layer violation" means "you have
> no business even trying to do this here".
>

Ok right yes parts should be moved to functions in filemerge. I will 
come around to that but it requires some refactoring so that code can be 
shared etc., I didn’t want to bite off too much at once without getting 
feedback first :).

However I don’t think the configured merge tool can deal with it 
perfectly; for one thing there is afaik no way to prevent it from 
popping up a merge dialog to the user, which is what I want to avoid. 
Also I wanted to do this all in memory without writing temporary files 
to disk and feeding it to external tools and such. Maybe that’s an 
unnecessary optimisation.

Anyway I thought using simplemerge in combination with a premerge flag 
check as described in the previous mail would be a good middle ground.

~Laurens

-- 
~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, developer, Utrecht, the Netherlands
Website: www.grauw.nl. Working @ www.roughcookie.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4332 bytes
Desc: S/MIME cryptografische ondertekening
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111221/dad6cf25/attachment.bin>