histedit: fix new nodes computation with --continue (
issue3534)
When running the following actions:
pick
617f94f13c0f 1 +4
drop
888f9082bf99 2 +5
fold
251d831eeec5 3 +6
if the fold fails, is fixed by the user with a new changeset, --continue
will ignore the new revision when generating the fold changelog. This
was caused by --continue detecting new changesets as descendants of the
parent not descendants of changesets in the initial list. In this case,
dropped changesets must be ignored.
Even with the computation fixed, the 'newchildren' list was always
emptied by the filtering loop and passed empty to finishfold().
Note that changesets dropped and recreated identically will still be
missed. This probably cannot be solved but is unlikely to happen.
Other things, like 'newchildren' having multiple heads, should be
checked as well.
histedit: end folding message with an LF
This is convenient when running tests dumping the editor content, it
avoids the following output line to be mixed with histedit message.
i18n-sv: synchronized with
d1b49b02bc16
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)
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.
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