largefiles: fix addremove with -R option

If a file was missing, the missing list contained a path relative to the repo.
When building the matcher from that list, the file name ended up concatenated to
cwd, causing the command to abort with '<file> not under root'.  This rebuilds
the missing list with paths relative to cwd.

--HG--
branch : stable
largefiles: defer lfdirstate.drop() until after commit (issue3364)

The example in comment #9 of the bug writeup must be run exactly- it was the
commit after the rm and prior to the addremove that screwed things up, because
that commit noticed that the largefile was missing, called drop(), and then the
original commit function did nothing (due to the file in the '!' state).  The
addremove command properly put it into the 'R' state, but it remained stuck in
that state (because commit insisted 'nothing changed').  Without the commit
prior to addremove, the problem didn't occur.

Maybe this is an indication that lfdirstate needs to take a few more hints from
the regular dirstate, regardless of what _it_ thinks the state is- similar
inconsistency is probably still possible with this patch if the original commit
succeeds but the lfdirstate write fails.

--HG--
branch : stable
largefiles: fix a traceback when addremove follows a remove (issue3507)

The problem only occurred if a file was removed with 'hg rm' (as opposed to the
OS utilities), and then addremove was run before a commit.  Both normal and
large files were affected.

Ensuring that the file exists prior to an lstat() for size seems like the Right
Thing.  But oddly enough, the missing file that was causing lstat() to blow up
was a standin when a largefile was removed, which seems fishy, because a standin
should never be added as a largefile.  I was then able to get a standin added as
a largefile (whose name is 'large') with

   hg addremove --config largefiles.patterns=**large

which also causes a backtrace.  That will be fixed next.

--HG--
branch : stable
largefiles: ensure addlargefiles() doesn't add a standin as a largefile

An easy way to force this (and cause a traceback) prior to the fix for 3507 was

  $ touch large
  $ hg add --large large
  $ hg ci -m "add"
  $ hg remove large
  $ touch large
  $ hg addremove --config largefiles.patterns=**large

This patch also detected (and corrected) a previous test where a standin got
added as a largefile (without a traceback).

--HG--
branch : stable
largefiles: mark as a first party extension

--HG--
branch : stable
test-largefiles: fix test failing on vfat file systems

The usercache hardlinks files for filesystems that support hardlinks. So when
this test is run on a filesystem that supports hardlinking, we have a link
in r7 and in the usercache, pointing to the same file contents (4cdac4d8...).

vfat does not support hardlinks, the file in the cache and in the store of
r7 are thus independent.

For the test to pass on vfat, we need to corrupt *both* the largefile in the
usercache and in the store of r7. Corrupting only one of them is not sufficient.

Fixes:

  --- /home/buildslave/mercurial/vfat_hg_tests__stable_/build/tests/test-largefiles.t
  +++ /home/buildslave/mercurial/vfat_hg_tests__stable_/build/tests/test-largefiles.t.err
  @@ -997,9 +997,11 @@
     $ hg push -R r7 http://localhost:$HGPORT1
     pushing to http://localhost:$HGPORT1/
     searching for changes
  -  remote: largefiles: failed to put 4cdac4d8b084d0b599525cf732437fb337d422a8 into store: largefile contents do not match hash
  -  abort: remotestore: could not put $TESTTMP/r7/.hg/largefiles/4cdac4d8b084d0b599525cf732437fb337d422a8 to remote store http://localhost:$HGPORT1/ (glob)
  -  [255]
  +  searching for changes
  +  remote: adding changesets
  +  remote: adding manifests
  +  remote: adding file changes
  +  remote: added 2 changesets with 2 changes to 2 files
     $ rm -rf empty

   Push a largefiles repository to a served empty repository

--HG--
branch : stable
i18n-sv: synchronized with d1b49b02bc16

--HG--
branch : stable
encoding: use s.decode to trigger UnicodeDecodeError

When calling encode on a str, the string is first decoded using the
default encoding and then encoded. So

  s.encode('ascii') == s.decode().encode('ascii')

We don't care about the encode step here -- we're just after the
UnicodeDecodeError raised by decode if it finds a non-ASCII character.

This way is also marginally faster since it saves the construction of
the extra str object.

--HG--
branch : stable
extra : rebase_source : a30b5e5999841034495194073e607fb6b4fa5609
encoding: add fast-path for ASCII uppercase.

This copies the performance hack from encoding.lower (c481761033bd).

The case-folding logic that kicks in on case-insensitive filesystems
hits encoding.upper hard: with a repository with 75k files, the
timings went from

  hg perfstatus
  ! wall 3.156000 comb 3.156250 user 1.625000 sys 1.531250 (best of 3)

to

  hg perfstatus
  ! wall 2.390000 comb 2.390625 user 1.078125 sys 1.312500 (best of 5)

This is a 24% decrease. For comparison, Mercurial 2.0 gives:

  hg perfstatus
  ! wall 2.172000 comb 2.171875 user 0.984375 sys 1.187500 (best of 5)

so we're only 10% slower than before we added the extra case-folding
logic.

The same decrease is seen when executing 'hg status' as normal, where
we go from:

  hg status --time
  time: real 4.322 secs (user 2.219+0.000 sys 2.094+0.000)

to

  hg status --time
  time: real 3.307 secs (user 1.750+0.000 sys 1.547+0.000)

--HG--
branch : stable
extra : rebase_source : 8ed3c13fe9737c5d3f683a1a0b44cc71fd77bbdc
util: delegate seek and tell methods of atomictempfile

--HG--
branch : stable
merge with crew-stable

--HG--
branch : stable
merge with i18n

--HG--
branch : stable