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

[Martin Geisler]

"Na'Tosha Bard" <natosha at unity3d.com> writes:

> 2011/12/14 Martin Geisler <mg at lazybytes.net>
>
>> [...] it was my impression that largefiles was (also) meant to be
>> used by people that work "actively" on the large files and so treat
>> them like real source artifacts for their product. Then it doesn't
>> make sense to just pick the newest image -- there has been some
>> communication problem if two artists have worked on the same image in
>> parallel and they have probably both had some intent with their
>> commits.
>
> Sure, but in the end it comes down to picking one or the other. The
> lack of communication and divergent work on something that can't be
> merged has already happened by the time we've gotten to this point.

Ah, I was imagining that Designer A would take his changes to the image
and put them into the image by Designer B. Maybe he moved a layer in a
big PhotoShop file and then we can move the image the same way in the
image he got from Designer B. In other words, hand-based merging.

>> 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.
>>
>
> Yes, it would certainly be useful to dump them into the working copy so the
> user can inspect them, but providing a display of interesting commit
> information about them is also relevant.

I completely agree -- getting 'hg log -r X' for the two commits that
last changed the large file would be a good start.

> I still don't understand the point of making it so people can set up
> their own merge tools, when it comes down to just picking one or the
> other. I don't see why we need an external set of merge tools for
> that. It just seems like it will complicate things for the user.

Yeah -- the idea of setting up merge tools is that people can use them
to pick one or the other with that. With 'hg resolve --tool
internal:local' for example.

-- 
Martin Geisler

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