README

largefiles: correctly download new largefiles when merging

There is a bug in the merge process where, if a new largefile is introduced
in a merge and the user does not have that largefile in his repo's local store
nor in his system cache, the working copy will retain the old largefile.  Upon
the commit of the merge, the standin is re-written to contain the hash of the
old largefile, and the lfdirstate retains a "Modified" status for the file.
The end result is that the largefile can show up in the merge commit as
"Modified", but the standin has no diff.  This is wrong in two ways:

  1) Such a "wedged" history with a nonsense change in a commit should not be
      possible
  2) It effectively reverts a largefile to an old version when doing a merge

This is caused by the fact that the updatelfiles() command always checks the
current largefile's hash against the hash stored in the current node's standin.
This is correct behavior in every case except for a merge.  When merging, we
must assume that the standin in the working copy contains the correct hash,
because the original hg.merge() has already updated it for us.

This patch fixes the issue by patching the repo object to carry a "_ismerging"
attribute, that the updatelfiles() command checks for.  When this attribute is
found, it checks against the working copy's standin, rather than the standin
in the current node.

Mercurial
=========

Mercurial is a fast, easy to use, distributed revision control tool
for software developers.

Basic install:

 $ make            # see install targets
 $ make install    # do a system-wide install
 $ hg debuginstall # sanity-check setup
 $ hg              # see help

See http://mercurial.selenic.com/ for detailed installation
instructions, platform-specific notes, and Mercurial user information.