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

Na'Tosha Bard natosha at unity3d.com
Tue Dec 13 16:08:14 CST 2011


2011/12/13 Martin Geisler <mg at lazybytes.net>

> 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.
>

I think if we printed something like:

keep (l)ocal or take (o)ther
(other is newer)

It would prevent a huge number of cases where the user must abort and find
out which one is the one he wants.  Most use cases with a binary file, if
you want the one that is newer -- it's a newer version of the library, or
an updated PNG image, or whatever.

>> 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.
>

As commented before, I don't think relying on the 'add' thresholds/patterns
is a good idea at all.  My opinion as a largefiles user is that letting the
human decide is best, and that automatically upgrading it to a largefile is
second best.


> >> 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.


I don't find largefiles confusing, but brittle (with some sharp edges) is a
good way to describe it :-)

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.

Cheers,
Na'Tosha

-- 
*Na'Tosha Bard*
Build & Infrastructure Developer | Unity Technologies

*E-Mail:* natosha at unity3d.com
*Skype:* natosha.bard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111213/2d7775ec/attachment.html>


More information about the Mercurial-devel mailing list