merge with i18n

i18n-ja: synchronized with 2478594b37c2

i1n-ru:synchronized with b748106fe616

i18n-pt_BR: synchronized with 0a730d3c5aae

merge: show renamed on one and deleted on the other side in debug output

merge: warn about file deleted in one branch and renamed in other (issue3074) For divergent renames the following message is printed during merge: note: possible conflict - file was renamed multiple times to: newfile file2 When a file is renamed in one branch and deleted in the other, the file still exists after a merge. With this change a similar message is printed for mv+rm: note: possible conflict - file was deleted and renamed to: newfile

tests: do not create repos inside repos in test-rename-merge1.t This is no actual problem, but I when adding more tests to this file, the directory structure would become t/repo2089/repoXXXX/repoYYYY/...

merge: do not warn about copy and rename in the same transaction (issue2113)

merge with stable

revpair: handle odd ranges (issue3474)

match: make 'match.files()' return list object always 'exact' match objects are sometimes created with a non-list 'pattern' argument: - using 'set' in queue.refresh():hgext/mq.py match = scmutil.matchfiles(repo, set(c[0] + c[1] + c[2] + inclsubs)) - using 'dict' in revert():mercurial/cmdutil.py (names = {}) m = scmutil.matchfiles(repo, names) 'exact' match objects return specified 'pattern' to callers of 'match.files()' as it is, so it is a non-list object. but almost all implementations expect 'match.files()' to return a list object, so this may causes problems: e.g. exception for "+" with another list object. this patch ensures that '_files' of 'exact' match objects is a list object. for non 'exact' match objects, parsing specified 'pattern' already ensures that it it a list one.

perf: add a perfdirstatewrite benchmark

parsers: cache the result of index_headrevs Although index_headrevs is much faster than its Python counterpart, it's still somewhat expensive when history is large. Since headrevs is called several times when the tag cache is stale or missing (e.g. after a strip or rebase), there's a win to be gained from caching the result, which we do here.

revlog: switch to a C version of headrevs The C implementation is more than 100 times faster than the Python version (which is still available as a fallback). In a repo with 330,000 revs and a stale .hg/cache/tags file, this patch improves the performance of "hg tip" from 2.2 to 1.6 seconds.

perf: rework perfheads and perftags to clear caches The cache clearing makes numbers more reproducible.

parsers: reduce raw_length when truncating When stripping revs, we now update raw_length to correctly reflect the new end of the index.

help: inline helper function used once only

help: remove redundant parameter

help: move some helper functions to help.py

help: remove dependency on ui from some helper functions

hg-ssh: refactor to have main() method Refactor hg-ssh to have a main() function instead of a bunch of top-level statements.

merge with stable

graphlog: turn getlogrevs() into a generator This improves the poor "time to first changeset" compared to the original log command. When running: $ hg log -u user log will enumerate the changelog and display matching revisions when they are found. But: $ hg log -G -u user will first find all revisions matching the user then start to display them. Initially, I considered turning revset.match() into a generator. This is doable but requires a fair amount of work. Instead, cmdutil.increasingwindows() is reused to call the revset matcher repeatedly. This has the nice properties of: - Let us reorder the windows after filtering, which is necessary as the matcher can reorder inputs but is an internal detail not a feature. - Let us feed the matcher with windows in changelog order, which is good for performances. - Have a generator designed for log-like commands, returning small windows at first then batching larger ones. I feel that calling the matcher multiple times is correct, at least with the revsets involved in getlogrevs() because they are: - stateless (no limit()) - respecting f(a|b) = f(a) | f(b), though I have no valid argument about that. Known issues compared to log code: - Calling the revset matcher multiple times can be slow when revset functions have to create expensive data structure for filtering. This will be addressed in a followup. - Predicate combinations like "--user foo --user bar" or "--user foo and --branch bar" are inherently slower because all input revision are checked against the first condition, then against the second, and so forth. log would enumerate the input revisions once and check each of them once against all conditions, which is faster. There are solutions but nothing cheap to implement. Some numbers against mozilla repository: first line total * hg log -u rnewman /Users/pmezard/bin/hg-2.2 0.148s 7.293s /Users/pmezard/bin/hgdev 0.132s 5.747s * hg log -u rnewman -u girard /Users/pmezard/bin/hg-2.2 0.146s 7.323s /Users/pmezard/bin/hgdev 0.136s 11.096s * hg log -l 10 /Users/pmezard/bin/hg-2.2 0.137s 0.153s /Users/pmezard/bin/hgdev 0.128s 0.144s * hg log -l 10 -u rnewman /Users/pmezard/bin/hg-2.2 0.146s 0.265s /Users/pmezard/bin/hgdev 0.133s 0.236s * hg log -b GECKO193a2_20100228_RELBRANCH /Users/pmezard/bin/hg-2.2 2.332s 6.618s /Users/pmezard/bin/hgdev 1.972s 5.543s * hg log xulrunner /Users/pmezard/bin/hg-2.2 5.829s 5.958s /Users/pmezard/bin/hgdev 0.194s 6.017s * hg log --follow xulrunner/build.mk /Users/pmezard/bin/hg-2.2 0.353s 0.438s /Users/pmezard/bin/hgdev 0.394s 0.580s * hg log -u girard tools /Users/pmezard/bin/hg-2.2 5.853s 6.012s /Users/pmezard/bin/hgdev 0.195s 6.030s * hg log -b COMM2000_20110314_RELBRANCH --copies /Users/pmezard/bin/hg-2.2 2.231s 6.653s /Users/pmezard/bin/hgdev 1.897s 5.585s * hg log --follow /Users/pmezard/bin/hg-2.2 0.137s 14.140s /Users/pmezard/bin/hgdev 0.381s 44.246s * hg log --follow -r 80000:90000 /Users/pmezard/bin/hg-2.2 0.127s 1.611s /Users/pmezard/bin/hgdev 0.147s 1.847s * hg log --follow -r 90000:80000 /Users/pmezard/bin/hg-2.2 0.130s 1.702s /Users/pmezard/bin/hgdev 0.368s 6.106s * hg log --follow -r 80000:90000 js/src/jsproxy.cpp /Users/pmezard/bin/hg-2.2 0.343s 0.388s /Users/pmezard/bin/hgdev 0.437s 0.631s * hg log --follow -r 90000:80000 js/src/jsproxy.cpp /Users/pmezard/bin/hg-2.2 0.342s 0.389s /Users/pmezard/bin/hgdev 0.442s 0.628s

cmdutil: extract increasing_windows() from walkchangerevs() It will be reused in the revset-based version.

httpclient: omit tests for the client since we don't run them anyway

httpclient: update to c5abd358e543 of httpplus

hgweb: make graph data suitable for template usage Previously, graph data has been encoded for processing done by JavaScript code run in the browser, employing simple structures with implicit member positions. This patch modifies the graph command to also produce data employing a dictionary-based structure suitable for use with the templating mechanism, thus permitting other ways of presenting repository graphs using that mechanism. In order to test these changes, the raw theme has been modified to include templates for graph nodes and edges. In a similar fashion, themes could employ technologies such as SVG that lend themselves to templating to produce the graph display. This patch makes use of a much simpler output representation than SVG in order to maintain clarity.

revset: fix infinite alias expansion detection The alias expansion code it changed from: 1- Get replacement tree 2- Substitute arguments in the replacement tree 3- Expand the replacement tree again into: 1- Get the replacement tree 2- Expand the replacement tree 3- Expand the arguments 4- Substitute the expanded arguments in the replacement tree and fixes cases like: [revsetalias] level1($1, $2) = $1 or $2 level2($1, $2) = level1($2, $1) $ hg log -r "level2(level1(1, 2), 3)" where the original version incorrectly aborted on infinite expansion error, because it was confusing the expanded aliases with their arguments.

revset: explicitely tag alias arguments for expansion The current revset alias expansion code works like: 1- Get the replacement tree 2- Substitute the variables in the replacement tree 3- Expand the replacement tree It makes it easy to substitute alias arguments because the placeholders are always replaced before the updated replacement tree is expanded again. Unfortunately, to fix other alias expansion issues, we need to reorder the sequence and delay the argument substitution. To solve this, a new "virtual" construct called _aliasarg() is introduced and injected when parsing the aliases definitions. Only _aliasarg() will be substituted in the argument expansion phase instead of all regular matching string. We also check user inputs do not contain unexpected _aliasarg() instances to avoid argument injections.

clone: add progress calls to uncompressed code path

merge with stable

util: fix bad variable use in bytecount introduced by f0f7f3fab315

acl: 'util.never' can be used instead of a more complex expression

acl: perform some computations earlier, so that returned lambda functions are simpler

acl: added some comments to easily identify branch- and path-based verifications

acl: 'util.never' used

acl: cleanup

revlog: don't handle long for revision matching The underlying C code doesn't support indexing by longs, there are no legitimate reasons to use a long, and longs should generally be converted to ints at a higher level by context's constructor.

merge with stable

context: grudging accept longs in constructor

win32: fix encoding handling for registry strings (issue3467) This stopped handling non-ASCII strings in 1.8

mpatch: use Py_ssize_t for string length

mpatch: use Py_ssize_t Eliminates mpatch.c(73) : warning C4244: 'return' : conversion from '__int64' to 'int', possible loss of data mpatch.c(299) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data mpatch.c(321) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data mpatch.c(335) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data mpatch.c(346) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data when compiling for Windows x64 target using the Microsoft compiler.

subrepo: make subrepo.subrepo(<not a subrepo path>) fail Until now, when calling subrepo.subrepo with a path at which there is no subrepo, a "nullstate" tuple would be returned. However, this is not very useful (the tuple can't really be used for creating a subrepo), so we'd just as soon have the function just fail, and leave it up to the caller to decide what to do. The motivation for doing this now is to simplify the solution for (issue3056).

merge with stable

hgweb: use ui.nontty to disable all cooked I/O

progress: use ui._isatty

pager: use ui._isatty infrastructure

ui: add _isatty method to easily disable cooked I/O

bdiff: check and cast first parameter value on putbe32() calls Eliminates mercurial/bdiff.c(383) : warning C4244: 'function' : conversion from '__int64' to 'uint32_t', possible loss of data mercurial/bdiff.c(384) : warning C4244: 'function' : conversion from '__int64' to 'uint32_t', possible loss of data mercurial/bdiff.c(385) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'uint32_t', possible loss of data when compiling for Windows x64 target using the Microsoft compiler.

bdiff: use Py_ssize_t instead of int Reduces the conversion warnings mercurial/bdiff.c(61) : warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data mercurial/bdiff.c(307) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data mercurial/bdiff.c(308) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data mercurial/bdiff.c(362) : warning C4244: '+=' : conversion from '__int64' to 'int', possible loss of data mercurial/bdiff.c(380) : warning C4244: '=' : conversion from '__int64' to 'int', possible loss of data mercurial/bdiff.c(381) : warning C4244: 'function' : conversion from '__int64' to 'uint32_t', possible loss of data mercurial/bdiff.c(382) : warning C4244: 'function' : conversion from '__int64' to 'uint32_t', possible loss of data mercurial/bdiff.c(416) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data to mercurial/bdiff.c(383) : warning C4244: 'function' : conversion from '__int64' to 'uint32_t', possible loss of data mercurial/bdiff.c(384) : warning C4244: 'function' : conversion from '__int64' to 'uint32_t', possible loss of data mercurial/bdiff.c(385) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'uint32_t', possible loss of data on the three putbe32() calls in the function bdiff when compiling for Windows x64 target using the Microsoft compiler.

doc: add detail explanation for 'present()' predicate of revsets

osutil: handle deletion race with readdir/stat (issue3463)

merge with stable

branchcache: backout 0311a6abd38a

dispatch: try and identify third-party extensions as sources of tracebacks Extension authors should explicitly declare their supported hg versions and include a buglink attribute in their extension. In the event that a traceback occurs, we'll identify the least-recently-tested extensionas the most likely source of the defect and suggest the user disable that extension. Packagers should make every effort to ship hg versions from exact tags, or with as few modifications as possible so that the versioning can work appropriately.

hgext: mark all first-party extensions as such

bookmarks: test that bare update forwards active bookmark

keyword: intentionally ignore check-code warning about unwrapped ui message

help: include bookmarks in 'help revisions' and simplify wording

merge with i18n

i18n-ru: synchronized with b490be1fec06

i18n-ru: correct `push --new-branch` description

bundle: make bundles more portable (isue3441) This is achieved by acting as if the user had given -r<rev> for each head rev of outgoing changesets on the command line, as well as appropriate --base <rev>. The discovery information is computed as normal, and then adjusted as above.

revset: fix traceback for bogus revisions in id(rev) hg log -r "id(1234567)" now returns an empty list like rev() does.

Makefile: remove generated mercurial/__version__.py

mq: rename --check into --keep-changes I named it --check because it felt like qpush & co were checking *more* things to ensure local changes could not be lost. But it has been pointed on the mailing list that --check is already used by update command with a meaning almost opposite to this one. An alternative was --keep but qfold and qdelete already have such an option to preserve patch files and qfold may be a candidate for --check. - qpush/qpop/qgoto --check becomes --keep-changes. - mq.check becomes mq.keepchanges. - The short option -c is dropped as -k may conflict with existing --keep. The availabilitity of mq.keepchanges should not make this too painful. - Fix minor reST mistake in option description.

parsers: use Py_CLEAR where appropriate

largefiles: fix addremove when largefile is missing (issue3227)

tags: short-circuit if no tags have ever been committed

largefiles: fix default clone destination regression

merge with crew

merge with stable

posix: workaround lack of TIOCGWINSZ on Irix (issue3449) On an Irix 6.5.24 system, TIOCGWINSZ is not available. This means that any usage of the "hg" tool that looks up the terminal size (e.g. "hg help") will fail with an AttributeError. A simple work-around is just to wrap this block in mercurial/posix.py with a try/except so that it ends up using the default 80 characters width.

phases: wrap docstrings at 70 characters

phases: fix typos in docstrings

largefiles: don't attempt to clone all largefiles to non-local destinations

hgweb: fix filediff base calculation Previously, we were finding the most recent version of a file in a changeset and comparing it against its first file parent. This was wrong on three counts: - it would show a diff in revisions where there was no change to a file - it would show a diff when only the exec bit changed - it would potentially compare against a much older changeset, which could be very expensive if git-style rename detection was enabled This compares the file in the current context with that context's parent, which may result in an empty diff when looking at a file not touched by the current changeset.

branches: improve performance by removing redundant operations This refactors the branches command so it collects all the information it needs about a branch in one pass over the branch map. In particular, it fixes an issue where the command called repo.branchtags() to get branch tips, and then used repo.branchheads() to get the closed/open status. Both repo methods read the changelog to determine if the branch is closed, resulting in extra, redundant I/O. For the PyPy repo with 744 branches and 843 branch heads, this brings hg branches over NFS from: CallCount Recursive Total(ms) Inline(ms) module:lineno(function) 2427 0 0.9057 0.9057 <open> 2424 0 0.4096 0.4096 <method 'close' of 'file' objects> 2424 0 0.0476 0.0476 <method 'read' of 'file' objects> 1 0 0.0468 0.0468 mercurial.revlog:637(headrevs) +1 0 0.0000 0.0000 +<len> 2422 0 0.0443 0.0443 <method 'seek' of 'file' objects> 2962 0 0.0337 0.0337 <zlib.decompress> 2491 0 1.8008 0.0322 mercurial.changelog:182(read) +2491 0 1.6982 0.0315 +mercurial.revlog:881(revision) +2488 0 0.0269 0.0134 +mercurial.changelog:28(decodeextra) +4982 0 0.0085 0.0085 +<method 'split' of 'str' objects> +4982 0 0.0274 0.0049 +mercurial.encoding:61(tolocal) +2491 0 0.0039 0.0039 +<method 'index' of 'str' objects> 2491 0 1.6982 0.0315 mercurial.revlog:881(revision) +2413 0 0.0112 0.0112 +mercurial.revlog:305(rev) +2491 0 1.5315 0.0068 +mercurial.revlog:847(_chunkraw) +2491 0 0.0414 0.0058 +mercurial.revlog:945(_checkhash) +2491 0 0.0028 0.0028 +mercurial.revlog:349(flags) +2491 0 0.0025 0.0025 +<mercurial.mpatch.patches> 2422 0 1.5089 0.0286 mercurial.revlog:818(_loadchunk) +2422 0 0.4093 0.4093 +<method 'close' of 'file' objects> +2422 0 0.0451 0.0451 +<method 'read' of 'file' objects> +2422 0 0.0443 0.0443 +<method 'seek' of 'file' objects> +2422 0 0.9703 0.0096 +mercurial.store:374(__call__) +2422 0 0.0079 0.0069 +mercurial.revlog:810(_addchunk) 5804 0 0.0204 0.0204 mercurial.revlog:305(rev) 2426 0 0.9552 0.0177 mercurial.scmutil:218(__call__) +2426 0 0.9057 0.9057 +<open> +2426 0 0.0120 0.0083 +os.path:80(split) +2426 0 0.0061 0.0049 +mercurial.scmutil:92(__call__) Time: real 1.950 secs (user 0.560+0.000 sys 0.220+0.000) down to: CallCount Recursive Total(ms) Inline(ms) module:lineno(function) 1545 0 0.6035 0.6035 <open> 1542 0 0.2697 0.2697 <method 'close' of 'file' objects> 1 0 0.0547 0.0547 mercurial.revlog:637(headrevs) +1 0 0.0000 0.0000 +<len> 1542 0 0.0389 0.0389 <method 'read' of 'file' objects> 1540 0 0.0316 0.0316 <method 'seek' of 'file' objects> 1853 0 0.0227 0.0227 <zlib.decompress> 1557 0 1.2131 0.0226 mercurial.changelog:182(read) +1557 0 1.1398 0.0221 +mercurial.revlog:881(revision) +1555 0 0.0199 0.0094 +mercurial.changelog:28(decodeextra) +3114 0 0.0058 0.0058 +<method 'split' of 'str' objects> +3114 0 0.0196 0.0035 +mercurial.encoding:61(tolocal) +1557 0 0.0026 0.0026 +<method 'index' of 'str' objects> 1557 0 1.1398 0.0221 mercurial.revlog:881(revision) +1557 0 1.0307 0.0047 +mercurial.revlog:847(_chunkraw) +1557 0 0.0287 0.0040 +mercurial.revlog:945(_checkhash) +1557 0 0.0018 0.0018 +<mercurial.mpatch.patches> +1557 0 0.0018 0.0018 +mercurial.revlog:326(node) +1557 0 0.0417 0.0013 +mercurial.revlog:857(_chunkbase) 1540 0 1.0147 0.0210 mercurial.revlog:818(_loadchunk) +1540 0 0.2693 0.2693 +<method 'close' of 'file' objects> +1540 0 0.0360 0.0360 +<method 'read' of 'file' objects> +1540 0 0.0316 0.0316 +<method 'seek' of 'file' objects> +1540 0 0.6487 0.0070 +mercurial.store:374(__call__) +1540 0 0.0059 0.0052 +mercurial.revlog:810(_addchunk) 3192 0 0.0173 0.0173 mercurial.revlog:305(rev) 8184 0 0.0300 0.0147 <method 'decode' of 'str' objects> +5204 0 0.0149 0.0048 +encodings.utf_8:15(decode) +1 0 0.0004 0.0000 +encodings:71(search_function) 43 26 0.0147 0.0129 <__import__> Time: real 1.390 secs (user 0.450+0.000 sys 0.170+0.000)

context: add changectx.closesbranch() method This removes the duplicated code for inspecting the 'close' extra field in a changeset.

localrepo: add branchtip() method for faster single-branch lookups For the PyPy repo with 744 branches and 843 branch heads, this brings hg log -r default over NFS from: CallCount Recursive Total(ms) Inline(ms) module:lineno(function) 3249 0 1.3222 1.3222 <open> 3244 0 0.6211 0.6211 <method 'close' of 'file' objects> 3243 0 0.0800 0.0800 <method 'read' of 'file' objects> 3241 0 0.0660 0.0660 <method 'seek' of 'file' objects> 3905 0 0.0476 0.0476 <zlib.decompress> 3281 0 2.6756 0.0472 mercurial.changelog:182(read) +3281 0 2.5256 0.0453 +mercurial.revlog:881(revision) +3276 0 0.0389 0.0196 +mercurial.changelog:28(decodeextra) +6562 0 0.0123 0.0123 +<method 'split' of 'str' objects> +6562 0 0.0408 0.0073 +mercurial.encoding:61(tolocal) +3281 0 0.0054 0.0054 +<method 'index' of 'str' objects> 3241 0 2.2464 0.0456 mercurial.revlog:818(_loadchunk) +3241 0 0.6205 0.6205 +<method 'close' of 'file' objects> +3241 0 0.0765 0.0765 +<method 'read' of 'file' objects> +3241 0 0.0660 0.0660 +<method 'seek' of 'file' objects> +3241 0 1.4209 0.0135 +mercurial.store:374(__call__) +3241 0 0.0122 0.0107 +mercurial.revlog:810(_addchunk) 3281 0 2.5256 0.0453 mercurial.revlog:881(revision) +3280 0 0.0175 0.0175 +mercurial.revlog:305(rev) +3281 0 2.2819 0.0119 +mercurial.revlog:847(_chunkraw) +3281 0 0.0603 0.0083 +mercurial.revlog:945(_checkhash) +3281 0 0.0051 0.0051 +mercurial.revlog:349(flags) +3281 0 0.0040 0.0040 +<mercurial.mpatch.patches> 13682 0 0.0479 0.0248 <method 'decode' of 'str' objects> +7418 0 0.0228 0.0076 +encodings.utf_8:15(decode) +1 0 0.0003 0.0000 +encodings:71(search_function) 3248 0 1.3995 0.0246 mercurial.scmutil:218(__call__) +3248 0 1.3222 1.3222 +<open> +3248 0 0.0235 0.0184 +os.path:80(split) +3248 0 0.0084 0.0068 +mercurial.scmutil:92(__call__) Time: real 2.750 secs (user 0.680+0.000 sys 0.360+0.000) down to: CallCount Recursive Total(ms) Inline(ms) module:lineno(function) 55 31 0.0197 0.0163 <__import__> +1 0 0.0006 0.0002 +mercurial.context:8(<module>) +1 0 0.0042 0.0001 +mercurial.revlog:12(<module>) +1 0 0.0002 0.0001 +mercurial.match:8(<module>) +1 0 0.0003 0.0001 +mercurial.dirstate:7(<module>) +1 0 0.0057 0.0001 +mercurial.changelog:8(<module>) 1 0 0.0117 0.0032 mercurial.localrepo:525(_readbranchcache) +844 0 0.0015 0.0015 +<binascii.unhexlify> +845 0 0.0010 0.0010 +<method 'split' of 'str' objects> +843 0 0.0045 0.0009 +mercurial.encoding:61(tolocal) +843 0 0.0004 0.0004 +<method 'setdefault' of 'dict' objects> +1 0 0.0003 0.0003 +<method 'close' of 'file' objects> 3 0 0.0029 0.0029 <method 'read' of 'file' objects> 9 0 0.0018 0.0018 <open> 990 0 0.0017 0.0017 <binascii.unhexlify> 53 0 0.0016 0.0016 mercurial.demandimport:43(__init__) 862 0 0.0015 0.0015 <_codecs.utf_8_decode> 862 0 0.0037 0.0014 <method 'decode' of 'str' objects> +862 0 0.0023 0.0008 +encodings.utf_8:15(decode) 981 0 0.0011 0.0011 <method 'split' of 'str' objects> 861 0 0.0046 0.0009 mercurial.encoding:61(tolocal) +861 0 0.0037 0.0014 +<method 'decode' of 'str' objects> 862 0 0.0023 0.0008 encodings.utf_8:15(decode) +862 0 0.0015 0.0015 +<_codecs.utf_8_decode> 4 0 0.0008 0.0008 <method 'close' of 'file' objects> 179 154 0.0202 0.0004 mercurial.demandimport:83(__getattribute__) +36 11 0.0199 0.0003 +mercurial.demandimport:55(_load) +72 0 0.0001 0.0001 +mercurial.demandimport:83(__getattribute__) +36 0 0.0000 0.0000 +<getattr> 1 0 0.0015 0.0004 mercurial.tags:148(_readtagcache) Time: real 0.060 secs (user 0.030+0.000 sys 0.010+0.000)

strip: introduce -B option to remove a bookmark Add a -B option to remove a bookmark. All revisions are unreachable from a different head or a different bookmark will be removed too. This helps with topic branch workflow. You can create a topic branch and remove it if not needed anymore with hg strip -B topic/xyz.

largefiles: use wlock for lfconvert (issue3444) largefiles and lfconvert do dirty hacks with dirstate, so to avoid writing that as a side effect of the wlock release we clear dirstate first. To avoid confusing lock validation algorithms in error situations we unlock _before_ removing the target directory.

localrepo: strip now incrementally updates the branchheads cache Destroying history via strip used to invalidate the branchheads cache, causing it to be regenerated the next time it is read. This is expensive in large repos. This change converts strip to pass info to localrepo.destroyed() to enable to it to incrementally update the cache, improving the performance of strip and other operations that depend on it (e.g., rebase). This change also strengthens a bit the integrity checking of the branchheads cache when it is read, by rejecting the cache if it has nodes in it that no longer exist.

phase: remove useless test, olddata is never None

test-rebase-collapse: fix Windows path separator

help: tweak keyword format output

help: link back to the help topics page from a specific topic page

help: add --keyword (-k) for searching help

help: introduce topicmatch for finding topics matching a keyword

extensions.disabled: return {} instead of None no extensions are disabled

merge: respect bookmarks during merge Bookmarks will behave more like named branches when merge tries to pick a revision to merge. Bookmarks now to respect the current bookmarks. Bookmarks will not accidentally merged with unnamed heads or other bookmarks. However merge can pick heads with diverging bookmarks and pick those automatically. We end up with two cases for picking a revision to merge: (1) In case of an current bookmark, merge can pick a branch head that has a diverged bookmark (2) In case of no current bookmark, merge can pick a branch head that does not have a bookmark.

localrepo: introduce bookmarkheads Similar to branch heads we introduce the notion of bookmarkheads. Bookmarkheads are changests that are bookmarked with the given bookmark or a diverged version

bookmarks: delete divergent bookmarks on merge

check-code: ignore naked excepts with a "re-raise" comment This also promotes the naked except check from a warning to an error.

check-code: improve detection of naked except clauses

cleanup: replace more naked excepts with more specific ones

check-code: promote 80+ character line warning to an error

cmdutil: use filectx.cmp() in amend()

largefiles: optimize performance when updating (issue3440) Previously, when updating, cachelfiles was called blindly on all largefiles in the repository at the revision being updated to, despite the fact that a list of which largefiles needs to be updated has already been collected. This optimization constrains the cachelfiles call to only the largefiles that need to be updated. On a repository with about 80 largefiles, updating between two revisions that only change one largefile goes from approximately 6.7 seconds to 3.3 seconds.

merge with stable

tests: make test-convert-darcs.t happier with darcs 2.8.0

bookmarks: pull new bookmarks from remote by default (BC)

rebase: allow collapsing branches in place (issue3111) We allow rebase plus collapse, but not collapse only? I imagine people would rebase first then collapse once they are sure the rebase is correct and it is the right time to finish it. I was reluctant to submit this patch for reasons detailed below, but it improves rebase --collapse usefulness so much it is worth the ugliness. The fix is ugly because we should be fixing the collapse code path rather than the merge. Collapsing by merging changesets repeatedly is inefficient compared to what commit --amend does: commitctx(), update, strip. The problem with the latter is, to generate the synthetic changeset, copy records are gathered with copies.pathcopies(). copies.pathcopies() is still implemented with merging in mind and discards information like file replaced by the copy of another, criss-cross copies and so forth. I believe this information should not be lost, even if we decide not to interpret it fully later, at merge time. The second issue with improving rebase --collapse is the option should not be there to begin with. Rebasing and collapsing are orthogonal and a dedicated command would probably enable a better, simpler ui. We should avoid advertizing rebase --collapse, but with this fix it becomes the best shipped solution to collapse changesets. And for the record, available techniques are: - revert + commit + strip: lose copies - mq/qfold: repeated patching() (mostly correct, fragile) - rebase: repeated merges (mostly correct, fragile) - collapse: revert + tag rewriting wizardry, lose copies - histedit: repeated patching() (mostly correct, fragile) - amend: copies.pathcopies() + commitctx() + update + strip

diffhelpers: use Py_ssize_t in testhunk() Eliminates mercurial/diffhelpers.c(143) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data mercurial/diffhelpers.c(144) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data when compiling for Windows x64 target using the Microsoft compiler.

diffhelpers: use Py_ssize_t in addlines() Eliminates mercurial/diffhelpers.c(81) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data mercurial/diffhelpers.c(82) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data when compiling for Windows x64 target using the Microsoft compiler.

diffhelpers: use Py_ssize_t in _fix_newline() Eliminates mercurial/diffhelpers.c(23) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data mercurial/diffhelpers.c(26) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data mercurial/diffhelpers.c(27) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data mercurial/diffhelpers.c(30) : warning C4244: 'initializing' : conversion from 'Py_ssize_t' to 'int', possible loss of data when compiling for Windows x64 target using the Microsoft compiler.

largefiles: add --all-largefiles flag to pull

largefiles: refactor downloading of all largefiles to generic function

unbundle: move bookmark update outside the lock d16c99f16f00 introduced updatecurrentbookmark after unbundle, but that path might end up taking a wlock after lock when writing the bookmarks.

cleanup: replace naked excepts with except Exception: ...

cleanup: replace naked excepts with more specific ones

cleanup: "raise SomeException()" -> "raise SomeException"

cleanup: "not x in y" -> "x not in y"

cleanup: replace hasattr() usage with getattr() in hghave

cleanup: "x != None" -> "x is not None"

cleanup: eradicate long lines

merge with i18n

mq: qimport need wlock for --push - do that after releasing lock qimport locking was introduced for phases in 29ea059be33c.

tag: run commit hook when lock is released (issue3344)