Matt Mackall <mpm@selenic.com> [Wed, 30 May 2012 14:31:39 -0500] rev 16800
merge with crew
Matt Mackall <mpm@selenic.com> [Wed, 30 May 2012 14:31:29 -0500] rev 16799
merge with i18n
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 29 May 2012 21:32:50 +0900] rev 16798
i18n-ja: synchronized with 2478594b37c2
Alexander Sauta <demosito@gmail.com> [Sun, 27 May 2012 15:37:36 +0100] rev 16797
i1n-ru:synchronized with b748106fe616
Wagner Bruna <wbruna@yahoo.com> [Sun, 27 May 2012 09:52:25 -0300] rev 16796
i18n-pt_BR: synchronized with 0a730d3c5aae
Thomas Arendsen Hein <thomas@intevation.de> [Wed, 23 May 2012 21:34:29 +0200] rev 16795
merge: show renamed on one and deleted on the other side in debug output
Thomas Arendsen Hein <thomas@intevation.de> [Wed, 23 May 2012 20:50:16 +0200] rev 16794
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
Thomas Arendsen Hein <thomas@intevation.de> [Wed, 23 May 2012 17:33:19 +0200] rev 16793
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/...
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)
Matt Mackall <mpm@selenic.com> [Wed, 30 May 2012 14:21:58 -0500] rev 16791
merge with stable
Matt Mackall <mpm@selenic.com> [Wed, 30 May 2012 14:13:57 -0500] rev 16790
revpair: handle odd ranges (issue3474)
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.
Bryan O'Sullivan <bryano@fb.com> [Wed, 16 May 2012 13:45:46 -0700] rev 16788
perf: add a perfdirstatewrite benchmark
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.
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.