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

[Matt Mackall]

On Fri, 2011-12-09 at 23:39 +0100, Na'Tosha Bard wrote:
> 2011/12/9 Matt Mackall <mpm at selenic.com>
> 
> > 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?
> >
> > > 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.
> >
> 
> This does seem like a logical conclusion, but I honestly think the prompt
> is the best way to go.  I can think of usecases when you would both upgrade
> a file to a largefile or downgrade it to a regular file.

Well I think we should print a note in any case.

> Or, apply the existing 'add' thresholds/patterns to decide.
> >
> 
> Please no, either err on the side of caution and upgrade it to a largefile,
> or let the human decide.  Even if there are defined thresholds/patterns,
> there can always be an exception (e.g, a 7 MB file that is getting replaced
> once per week.  It's not high enough to hit the golden 10 MB limit, but
> it's getting replaced often enough that it matters if it's a largefile or
> not.

Fair enough.

> > > 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, I am envisioning a lot of confused looks on developers' faces -- could
> we somehow indicate in the status output what is going on better?  Or is
> tinkering with basic status output a no-no?

Well I think if it shows up in status at all, we're doing it wrong.

-- 
Mathematics is the supreme nostalgia of our time.