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

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).

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.

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.

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.

dispatch: fix traceback when extension was tested with newer versions only The "worst" extension still is the one tested with the lowest tested version below the current version of Mercurial, but if an extension with was only tested with newer versions, it is considered a candidate for a bad extension, too. In this case extensions which have been tested with higher versions of Mercurial are considered better. This allows finding the oldest extension if ct can't be calculated correctly and therefore defaults to an empty tuple, and it involves less changes to the comparison logic during the current code freeze.

test-extension.t: use fixed version string instead of current tag Currently tests break with the current tag being 2.3-rc and tags set by the user could affect this test, too.

Added tag 2.3-rc for changeset a06e2681dd17

merge default into stable for 2.3 code freeze

merge with crew

merge with stable

windows: removed duplicate termwidth definition Changeset dbf91976f900 caused this when the "from win32 import *" line was replaced with explicit import statements: the wildcard import was at the bottom of the file and so windows.termwidth was overwritten by win32.termwidth as indented, but the new explicit import statements were at the top and so win32.termwidth got lost. With the switch to ctypes, win32 can always be imported and so the fallback termwidth in windows is no longer needed.

httprepo: ensure Content-Type header exists when pushing data Otherwise the wireprotocol just hangs while trying to send data. (And nothing is received at the other side)

obsolete: obsstore.add now takes a list of markers. This allow efficient IO and it greatly simplify the merging of markers.

obsolete: refactor writemarkers to only encode them The function is now able to write the version header as necessary. The function now yield bytes to be written to a stream. This should ease later use of this function for wireprotocol based exchanged. Prepare the public use of the writemarker by wireprotocol function.

update: put rules for uncommitted changes into verbose help section

hooks: print out more information when loading a python hook fails When loading a python hook with file syntax fails, there is no information that this happened while loading a hook. When the python file does not exist even the file name is not printed. (Only that a file is missing.) This patch adds this information and a test for loading a non existing file and a directory not being a python module.

perf: fix perfcca to work with new casecollisionauditor interface A recent changeset, afd75476939e, modified the caescollisionauditor interface but did not update perf.py. This changeset remidies that.

checkheads: extract branchmap preprocessing The checkheads function is far too complicated. This extract help to explicite what part of the preprocessing are reused by the actual check. This the first step toward a wider refactoring.

checkheads: take future obsoleted heads into account If we push some successors they will likely create a new head on remote. However as the obsoleted head will disappear after the push we are not really increasing the number of heads. There is several case which will lead to extra being actually pushed. But this first changeset aims to be simple. See the inline comment for details. Without this change, you need to push --force every time you want to push a newer version which is very error prone. The remote side still display +n heads on unbundle because it does not have the obsolete marker at unbundle time.

obsolete: add an any successors function This function yield every nodes which succeed to a group of nodes. The first user will be checkheads who need to know if we push successors for remote extra heads.

checkheads: extract bookmark computation from the branch loop No branch specific data are used in the computation of the bookmarked heads. We can only compute it once.

checkheads: simplify the structure build by preprocessing All useful data are now gathered in a single dictionnary. `branchmapsummary` is renamed to `headssummary` and its return value is greatly simplified.

_updatebranchcache: prevent deleting dict key during iteration We use dict.keys() to fetch all keys before starting to delete some. Otherwise python complains that the dictionnary is altered during iteration.