Wed, 23 May 2012 17:25:48 +0200 merge: do not warn about copy and rename in the same transaction (issue2113)
Thomas Arendsen Hein <thomas@intevation.de> [Wed, 23 May 2012 17:25:48 +0200] rev 16792
merge: do not warn about copy and rename in the same transaction (issue2113)
Wed, 30 May 2012 14:21:58 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Wed, 30 May 2012 14:21:58 -0500] rev 16791
merge with stable
Wed, 30 May 2012 14:13:57 -0500 revpair: handle odd ranges (issue3474) stable
Matt Mackall <mpm@selenic.com> [Wed, 30 May 2012 14:13:57 -0500] rev 16790
revpair: handle odd ranges (issue3474)
Wed, 23 May 2012 00:25:29 +0900 match: make 'match.files()' return list object always stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 23 May 2012 00:25:29 +0900] rev 16789
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.
Wed, 16 May 2012 13:45:46 -0700 perf: add a perfdirstatewrite benchmark
Bryan O'Sullivan <bryano@fb.com> [Wed, 16 May 2012 13:45:46 -0700] rev 16788
perf: add a perfdirstatewrite benchmark
Sat, 19 May 2012 20:21:48 -0700 parsers: cache the result of index_headrevs
Bryan O'Sullivan <bryano@fb.com> [Sat, 19 May 2012 20:21:48 -0700] rev 16787
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.
Sat, 19 May 2012 19:44:58 -0700 revlog: switch to a C version of headrevs
Bryan O'Sullivan <bryano@fb.com> [Sat, 19 May 2012 19:44:58 -0700] rev 16786
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.
Sat, 19 May 2012 19:44:23 -0700 perf: rework perfheads and perftags to clear caches
Bryan O'Sullivan <bryano@fb.com> [Sat, 19 May 2012 19:44:23 -0700] rev 16785
perf: rework perfheads and perftags to clear caches The cache clearing makes numbers more reproducible.
Sat, 19 May 2012 19:44:18 -0700 parsers: reduce raw_length when truncating
Bryan O'Sullivan <bryano@fb.com> [Sat, 19 May 2012 19:44:18 -0700] rev 16784
parsers: reduce raw_length when truncating When stripping revs, we now update raw_length to correctly reflect the new end of the index.
Tue, 22 May 2012 22:08:41 +0200 help: inline helper function used once only
Olav Reinert <seroton10@gmail.com> [Tue, 22 May 2012 22:08:41 +0200] rev 16783
help: inline helper function used once only
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip