Matt Mackall <mpm@selenic.com> [Tue, 24 Jul 2012 12:36:40 -0500] rev 17240
merge with i18n
Jens Bäckman <jens.backman@gmail.com> [Mon, 23 Jul 2012 20:38:33 +0200] rev 17239
i18n-sv: synchronized with d1b49b02bc16
Bryan O'Sullivan <bryano@fb.com> [Mon, 23 Jul 2012 15:40:19 -0700] rev 17238
merge with crew-stable
Bryan O'Sullivan <bryano@fb.com> [Mon, 23 Jul 2012 15:38:43 -0700] rev 17237
util: delegate seek and tell methods of atomictempfile
Martin Geisler <mg@aragost.com> [Mon, 23 Jul 2012 15:55:26 -0600] rev 17236
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)
Martin Geisler <mg@aragost.com> [Mon, 23 Jul 2012 15:55:22 -0600] rev 17235
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.
Adrian Buehlmann <adrian@cadifra.com> [Sun, 22 Jul 2012 13:16:45 +0200] rev 17234
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
Matt Harbison <matt_harbison@yahoo.com> [Fri, 20 Jul 2012 22:10:52 -0400] rev 17233
largefiles: mark as a first party extension