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

[Martin Geisler]

Matt Mackall <mpm at selenic.com> writes:

> On Fri, 2011-12-09 at 18:05 +0100, Martin Geisler wrote:
>> # HG changeset patch
>> # User Martin Geisler <mg at aragost.com>
>> # Date 1323448500 -3600
>> # Branch stable
>> # Node ID f9390ba27de9bc3661b2b2bb83a3ce9e81f41772
>> # Parent  5b66e55c0d938a524c0b6e933010c7a5f728bc30
>> largefiles: handle merges between normal files and largefiles (issue3084)
>> 
>> The largefiles extension prevents users from adding a normal file
>> named 'foo' if there is already a largefile with the same name.
>> However, there was a loop-hole: when merging, it was possible to bring
>> in a normal file named 'foo' while also having a '.hglf/foo' file.
>
> Do largefiles never go through filemerge?

No, not really. They do run run through filemerge.filemerge, but it only
offers users this prompt:

  largefile %s has a merge conflict
  keep (l)ocal or take (o)ther?

Seems a bit limited to me, to be honest, since users will probably need
to abort the choose blindly at this point and then dump the two versions
by hand.

>> This patch fixes this by extending the manifest merge to deal with
>> these kinds of conflicts. If there is a normal file 'foo' in the
>> working copy, and the other parent brings in a '.hglf/foo' file, then
>> the user will be prompted to keep the normal file or the largefile.
>> Likewise for the symmetric case where a normal file is brought in via
>> the second parent. The prompt looks like this:
>
> Seems to me we should just always promote files to largefiles on
> merge. Or, apply the existing 'add' thresholds/patterns to decide.

Yeah, I also wanted to do this at some point, but Na'Tosha told me she
was fine with the simpler solution of just prompting so I went with that
first. I'll have to look at things again to figure out if/how an upgrade
patch could look.

>> The status and diff output looks peculiar after a merge where the type
>> of a file changed. If a normal file 'foo' was changed to a largefile,
>> then we get:
>> 
>>   $ hg status
>>   M foo
>>   R foo
>
> Eep. That's seriously ugly.

Yes, agreed :) After looking at the largefiles code I'm afraid I find
the whole concept rather ugly. Basically all commands need wrapping and
adapting to make '.hglf/x' and 'x' be the same file. It feels brittle
and confusing. More papering over could of course hide the output above,
but it is in some way what you would expect when you have these two
files for every largefile.

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111213/34a6b64a/attachment.pgp>