[PATCH stable] largefiles: handle merges between normal files and largefiles (issue3084)

[Martin Geisler]

Matt Mackall <mpm at selenic.com> writes:

> On Wed, 2011-12-14 at 00:17 +0100, Martin Geisler wrote:
>> "Na'Tosha Bard" <natosha at unity3d.com> writes:
>> 
>> > 2011/12/13 Martin Geisler <mg at lazybytes.net>
>> 
>> Based on that, I think that we'll at least need something like
>> internal:dump here. It writes the two versions of the file to the
>> working copy so that the user can inspect them. Ideally, we would get
>> the normal merge machinery to work like normal so that people could
>> setup their own merge tools, e.g., a tool that picks the newer file.
>
> Really, I'd like these complex merge decisions to be something you can
> defer and then come back and do "hg resolve somefile" and get an
> appropriate prompt. Steve worked on this, but I never understood his
> patch.

Right -- it's important that 'hg resolve' works on this. I just tested
it without my patch, and resolve is not wrapped: it shows '.hglf/foo'
instead of 'foo'. You can then re-merge by resolving '.hglf/foo'.

My patch hooks into manifestmerge and so you cannot re-merge. That's of
course kind of stupid... My thinking was that manifest merge is the
right place since I need to deal with inter-file conflicts when 'foo' is
brought in by a branch and '.hglf/foo' is already there.

> Your internal:dump idea is interesting, but a little unfortunate in the
> context of largefiles. Also, does it dump the ancestor, or just "other"?
> We've already got "local" by definition.

It copies the local 'foo' to 'foo.local' and writes 'foo.other' and
'foo.base' files. So that might be expensive for big files.

>> > I think conceptually, I would expect to see:
>> >
>> > $ hg status
>> > M foo
>> >
>> > Becuase *conceptually*, foo is the same file, whether it is a
>> > largefile, or a regular file. What the best thing to actually show
>> > in hg status is a bit hard to say.
>> 
>> I think that's the right thing to show as well.
>
> We might need a cleaner, more self-contained hack underneath so that
> it's more transparent at higher levels and needs fewer wrappers.

Yes, I hope that's possible somehow.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/