convert/svn: handle non-local svn destination paths (issue3142) test-convert-svn-sink.t still pass and I tested pushing to an svn+ssh repository

setup: fix build_hgexe for mingw32 compiler Fixes python setup.py build_hgexe -i --compiler=mingw32

largefiles: fix path handling for cp/mv (issue3516) Previously, a copy or a move of a largefile only worked if the cwd was the root of the repository. The first issue was that the destination path passed to os.mkdirs() chopped the absolute path to the standin after '.hglf/', which essentially created a path relative to the repository root. Similarly, the second issue was that the source and dest paths for copyfile() were relative to the repo root. This converts these three paths to absolute paths. Some notable issues, regardless of the directory in which the cp/mv is executed: 1) The copy is not being recorded in lfdirstate, but it is in dirstate for the standins. I'm not sure if this is by design (i.e. minimal info in lfdirstate). 2) status -C doesn't behave as expected. Using the testcase as an example: # after mv + ci $ hg status -C -v --rev '.^' # expected to see 'A' and ' ' lines too R dira\dirb\largefile $ hg status -C -v --rev '.^' foo/largefile # no output # expected to see 'A' and ' ' lines only $ hg status -C -v --rev '.^' foo/ # no output # expected to see 'A', ' ' and 'R' lines $ hg status -C -v --rev '.^' ./ # expected to see 'A' and ' ' lines too R dirb\largefile $ hg status -C -v --rev '.^' ../.hglf/dira/foo/largefile A ..\.hglf\dira\foo\largefile ..\.hglf\dira\dirb\largefile # no 'R' expected when new file is specified $ hg status -C -v --rev '.^' ../.hglf # OK A ..\.hglf\dira\foo\largefile ..\.hglf\dira\dirb\largefile R ..\.hglf\dira\dirb\largefile

revset: add explanation about difference between 'filelog()' and 'file()'

hgweb: improve colors for comparison page delete: red -> red insert: green -> yellow change: yellow -> gray

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.

merge with i18n

i18n-sv: synchronized with d1b49b02bc16

merge with crew-stable

util: delegate seek and tell methods of atomictempfile

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

largefiles: mark as a first party extension