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.

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.

graphlog: implement --follow with file arguments

test-glog: test multiple --prune values

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.

glog: restore multiple --rev test lost in rebasing

copies: remove checkdirs options This removes the undocumented merge.followdirs option, which has always been true.

copies: add docstring for mergecopies

addremove: return 1 if we failed to handle any explicit files

merge with stable

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.

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.

graft: use proper revisions for copy detection (issue3265)

convert: fix typos in error messages

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.