Sun, 26 Feb 2012 16:45:59 -0600 copies: use ctx.dirs() for directory rename detection
Matt Mackall <mpm@selenic.com> [Sun, 26 Feb 2012 16:45:59 -0600] rev 16178
copies: use ctx.dirs() for directory rename detection
Sun, 26 Feb 2012 15:51:56 -0600 copies: fix mergecopies doc mapping direction
Matt Mackall <mpm@selenic.com> [Sun, 26 Feb 2012 15:51:56 -0600] rev 16177
copies: fix mergecopies doc mapping direction
Sat, 25 Feb 2012 16:48:07 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Sat, 25 Feb 2012 16:48:07 -0600] rev 16176
merge with stable
Sat, 25 Feb 2012 19:39:55 +0100 log: restore cache used by --copies stable
Patrick Mezard <patrick@mezard.eu> [Sat, 25 Feb 2012 19:39:55 +0100] rev 16175
log: restore cache used by --copies The {filelog -> linkrev -> copyfrom} cache was refactored and broken by: changeset: 10060:f780b1098efc user: Patrick Mezard <pmezard@gmail.com> date: Sun Dec 13 18:06:24 2009 +0100 summary: templatekw: change {file_copies} behaviour, add {file_copies_switch} With --copies, this cache is accessed for every touched file of every revision. Unfortunately it is recreated for every revision, which means filelogs are parsed again. This patch makes the cache global again for all revisions. A couple of indicative timings of "hg log --copies", before and after: hg: 44s / 5s mozilla --limit 10000: 3m51s / 2m32s mozilla: 23m46s / 12m23s I do not know any good tool to trace memory consumption of these runs for comparisons. Watching the full mozilla run in top, the process did not seem to misbehave.
Sat, 25 Feb 2012 22:11:36 +0100 graphlog: implement --follow-first
Patrick Mezard <patrick@mezard.eu> [Sat, 25 Feb 2012 22:11:36 +0100] rev 16174
graphlog: implement --follow-first log --graph --follow-first FILE cannot be compared with the regular version because it never worked: --follow-first is not taken in account in walkchangerevs() fast path and is explicitely bypassed in FILE case in walkchangerevs() nested iterate() function.
Sat, 25 Feb 2012 22:11:36 +0100 graphlog: implement --follow with file arguments
Patrick Mezard <patrick@mezard.eu> [Sat, 25 Feb 2012 22:11:36 +0100] rev 16173
graphlog: implement --follow with file arguments
Sat, 25 Feb 2012 22:11:35 +0100 test-glog: test multiple --prune values
Patrick Mezard <patrick@mezard.eu> [Sat, 25 Feb 2012 22:11:35 +0100] rev 16172
test-glog: test multiple --prune values
Sat, 25 Feb 2012 22:11:34 +0100 graphlog: restore FILE glob expansion on Windows
Patrick Mezard <patrick@mezard.eu> [Sat, 25 Feb 2012 22:11:34 +0100] rev 16171
graphlog: restore FILE glob expansion on Windows On platforms not supporting shell expansion, scmutil.match() performs glob expansion on 'pats' arguments. But _matchfiles() revset calls match.match() directly, bypassing this behaviour. To avoid duplicating scmutil.match(), a secondary scmutil.matchandpats() is introduced returning both the match object and the expanded inputs. Note the expanded pats are also needed in the fast path, and will be used by --follow code path.
Sat, 25 Feb 2012 21:51:13 +0100 glog: restore multiple --rev test lost in rebasing
Patrick Mezard <patrick@mezard.eu> [Sat, 25 Feb 2012 21:51:13 +0100] rev 16170
glog: restore multiple --rev test lost in rebasing
Sat, 25 Feb 2012 14:22:58 -0600 copies: remove checkdirs options
Matt Mackall <mpm@selenic.com> [Sat, 25 Feb 2012 14:22:58 -0600] rev 16169
copies: remove checkdirs options This removes the undocumented merge.followdirs option, which has always been true.
Fri, 24 Feb 2012 18:21:06 -0600 copies: add docstring for mergecopies
Matt Mackall <mpm@selenic.com> [Fri, 24 Feb 2012 18:21:06 -0600] rev 16168
copies: add docstring for mergecopies
Fri, 24 Feb 2012 16:52:32 -0600 addremove: return 1 if we failed to handle any explicit files
Matt Mackall <mpm@selenic.com> [Fri, 24 Feb 2012 16:52:32 -0600] rev 16167
addremove: return 1 if we failed to handle any explicit files
Fri, 24 Feb 2012 16:16:48 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Fri, 24 Feb 2012 16:16:48 -0600] rev 16166
merge with stable
Fri, 24 Feb 2012 20:57:59 +0100 log: fix --follow FILE ancestry calculation stable
Patrick Mezard <patrick@mezard.eu> [Fri, 24 Feb 2012 20:57:59 +0100] rev 16165
log: fix --follow FILE ancestry calculation Currently, --follow FILE looks for a FILE filelog, scans it and collects linkrevs and renames, then filters them. The problem is the filelog scan does not start at FILE filenode in parent revision but at the last filelog revision. So: - Files not in the parent revision can be followed, the starting node is unexpected - Files in the parent revision can be followed from an incorrect starting node. This patch makes log --follow FILE fail if FILE is not in parent revision, and computes ancestors of the parent revision FILE filenode.
Fri, 24 Feb 2012 20:56:18 +0100 test-glog: extend a test before fixing --follow issues stable
Patrick Mezard <patrick@mezard.eu> [Fri, 24 Feb 2012 20:56:18 +0100] rev 16164
test-glog: extend a test before fixing --follow issues The changes add a lot of noise to the test output, I prefer to separate it from the changes which are to be introduced by --follow fixes.
Fri, 24 Feb 2012 16:09:15 -0600 graft: use proper revisions for copy detection (issue3265) stable
Matt Mackall <mpm@selenic.com> [Fri, 24 Feb 2012 16:09:15 -0600] rev 16163
graft: use proper revisions for copy detection (issue3265)
Fri, 24 Feb 2012 19:11:35 -0200 convert: fix typos in error messages stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Fri, 24 Feb 2012 19:11:35 -0200] rev 16162
convert: fix typos in error messages
Thu, 23 Feb 2012 18:05:20 +0100 graphlog: paths/-I/-X handling requires a new revset
Patrick Mezard <patrick@mezard.eu> [Thu, 23 Feb 2012 18:05:20 +0100] rev 16161
graphlog: paths/-I/-X handling requires a new revset The filtering logic of match objects cannot be reproduced with the existing revsets as it operates at changeset files level. A changeset touching "a" and "b" is matched by "-I a -X b" but not by "file(a) and not file(b)". To solve this, a new internal "_matchfiles(...)" revset is introduced. It works like "file(x)" but accepts more than one argument and its arguments are prefixed with "p:", "i:" and "x:" to be used as patterns, include patterns or exclude patterns respectively. The _matchfiles revset is kept private for now: - There are probably smarter ways to pass the arguments in a user-friendly way - A "rev:" argument is likely appear at some point to emulate log command behaviour with regard to filesets: they are evaluated for the parent revision and applied everywhere instead of being reevaluated for each revision.
Thu, 23 Feb 2012 17:55:07 +0100 graphlog: imitate log slowpath when inputs are explicit files
Patrick Mezard <patrick@mezard.eu> [Thu, 23 Feb 2012 17:55:07 +0100] rev 16160
graphlog: imitate log slowpath when inputs are explicit files
Thu, 23 Feb 2012 17:54:42 +0100 graphlog: paths arguments must be or'ed
Patrick Mezard <patrick@mezard.eu> [Thu, 23 Feb 2012 17:54:42 +0100] rev 16159
graphlog: paths arguments must be or'ed
Thu, 23 Feb 2012 11:21:30 +0100 graphlog: rewrite --rev like all other options
Patrick Mezard <patrick@mezard.eu> [Thu, 23 Feb 2012 11:21:30 +0100] rev 16158
graphlog: rewrite --rev like all other options
Thu, 23 Feb 2012 11:21:04 +0100 graphlog: --branch and --only-branch are the same
Patrick Mezard <patrick@mezard.eu> [Thu, 23 Feb 2012 11:21:04 +0100] rev 16157
graphlog: --branch and --only-branch are the same Handling the aliasing in fancyopts would be cleaner but I do not want to make this change for stable.
Thu, 23 Feb 2012 17:46:57 +0100 test-check-code-hg: fix xargs exit status on OSX stable
Patrick Mezard <patrick@mezard.eu> [Thu, 23 Feb 2012 17:46:57 +0100] rev 16156
test-check-code-hg: fix xargs exit status on OSX When xargs subcommand invocation fails in a normal way, GNU xargs returns 123 and BSD one returns 1.
Thu, 23 Feb 2012 13:37:10 +0100 largefiles: respect store.createmode and avoid extra file copy stable
Martin Geisler <mg@aragost.com> [Thu, 23 Feb 2012 13:37:10 +0100] rev 16155
largefiles: respect store.createmode and avoid extra file copy Before, a tempfile was used to create a temp file was created with 600 permissions and the uploaded data was written into it. This file was then *copied* to .hg/largefiles/<hash>. We now simply use atomictempfile to write the data to a temp file with the right permissions and then rename that into place.
Thu, 23 Feb 2012 13:37:10 +0100 largefiles: respect store.createmode in basestore.get stable
Martin Geisler <mg@aragost.com> [Thu, 23 Feb 2012 13:37:10 +0100] rev 16154
largefiles: respect store.createmode in basestore.get This replaces another use of tempfile with atomictempfile. The problem with tempfile is that it creates files with 600 permissions instead of respecting repo.store.createmode.
Thu, 23 Feb 2012 13:22:55 +0100 largefiles: use repo.store.createmode for new files in .hg/largefiles stable
Martin Geisler <mg@aragost.com> [Thu, 23 Feb 2012 13:22:55 +0100] rev 16153
largefiles: use repo.store.createmode for new files in .hg/largefiles Before, the mode was copied from the file in the working copy. This is inconsistent with how Mercurial normally creates files inside the .hg folder. This can lead to a situation where you can read the files under .hg/store but not under .hg/largefiles and so a clone will fail if it needs to access a largefile.
Wed, 22 Feb 2012 17:41:22 -0600 mq: expand qimport summary
Matt Mackall <mpm@selenic.com> [Wed, 22 Feb 2012 17:41:22 -0600] rev 16152
mq: expand qimport summary
Wed, 22 Feb 2012 17:36:33 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Wed, 22 Feb 2012 17:36:33 -0600] rev 16151
merge with stable
(0) -10000 -3000 -1000 -300 -100 -50 -28 +28 +50 +100 +300 +1000 +3000 +10000 +30000 tip