Thu, 16 Feb 2012 13:03:42 +0100 import: handle git renames and --similarity (issue3187) stable
Patrick Mezard <patrick@mezard.eu> [Thu, 16 Feb 2012 13:03:42 +0100] rev 16112
import: handle git renames and --similarity (issue3187) There is no reason to discard copy sources from the set of files considered by addremove(). It was done to handle the case where a first patch would create 'a' and a second one would move 'a' to 'b'. If these patches were applied with --no-commit, 'a' would first be marked as added, then unlinked and dropped from the dirstate but still passed to addremove(). A better fix is thus to exclude removed files which ends being dropped from the dirstate instead of removed. Reported by Jason Harris <jason@jasonfharris.com>
Thu, 16 Feb 2012 12:56:48 +0100 context: make workingctx.forget() really warn about untracked files stable
Patrick Mezard <patrick@mezard.eu> [Thu, 16 Feb 2012 12:56:48 +0100] rev 16111
context: make workingctx.forget() really warn about untracked files
Wed, 15 Feb 2012 23:01:09 +0900 largefiles: check whether specified patterns are related to largefiles strictly stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 15 Feb 2012 23:01:09 +0900] rev 16110
largefiles: check whether specified patterns are related to largefiles strictly current 'lfiles_repo.status()' implementation examines whether specified patterns are related to largefiles in working directory (not to STANDIN) or not by NOT-EMPTY-NESS of below list: [f for f in match.files() if f in lfdirstate] but it can not be assumed that all in 'match.files()' are file itself exactly, because user may only specify part of path to match whole under subdirectories recursively. above examination will mis-recognize such pattern as 'not related to largefiles', and executes normal 'status()' procedure. so, 'hg status' shows '?'(unknown) status for largefiles in working directory unexpectedly. this patch examines relation of pattern to largefiles by applying 'match()' on each entries in lfdirstate and checking wheter there is no matched entry. it may increase cost of examination, because it causes of full scan of entries in lfdirstate. so this patch uses normal for-loop instead of list comprehensions, to decrease cost when matching is found.
Fri, 10 Feb 2012 17:09:23 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Fri, 10 Feb 2012 17:09:23 -0600] rev 16109
merge with stable
Fri, 10 Feb 2012 16:52:32 -0600 log: remove caching of all visited revisions (issue3253) stable
Matt Mackall <mpm@selenic.com> [Fri, 10 Feb 2012 16:52:32 -0600] rev 16108
log: remove caching of all visited revisions (issue3253) Not only does this eat all available memory for some users, it's slower.
Fri, 10 Feb 2012 16:09:30 -0600 pull: backout change to return code stable
Matt Mackall <mpm@selenic.com> [Fri, 10 Feb 2012 16:09:30 -0600] rev 16107
pull: backout change to return code This bit a number of people.
Fri, 10 Feb 2012 22:34:13 +0100 convert: use splicemap entries when sorting revisions (issue1748) stable
Patrick Mezard <patrick@mezard.eu> [Fri, 10 Feb 2012 22:34:13 +0100] rev 16106
convert: use splicemap entries when sorting revisions (issue1748) When sorting revisions before converting them, we have to edit the revision graph using splicemap entries. Otherwise, a spliced revision may be converted before its synthetic parents. Invalid splicemap revisions are now detected before starting the conversion.
Fri, 10 Feb 2012 22:25:49 +0100 convert: turn splicemap into a simple dictionary stable
Patrick Mezard <patrick@mezard.eu> [Fri, 10 Feb 2012 22:25:49 +0100] rev 16105
convert: turn splicemap into a simple dictionary Parsing the splicemap as a mapfile was a pain because map does not let us override its parsing code and splicemap entries are not key/values. Besides we had no need for mapfiles extra features. Just parse the splicemap and return a dictionary.
Fri, 10 Feb 2012 13:50:13 +0100 debugrevspec: mention --verbose to print the parsed tree
Patrick Mezard <patrick@mezard.eu> [Fri, 10 Feb 2012 13:50:13 +0100] rev 16104
debugrevspec: mention --verbose to print the parsed tree
Fri, 10 Feb 2012 14:46:09 +0100 largefiles: only cache largefiles in new heads stable
Na'Tosha Bard <natosha@unity3d.com> [Fri, 10 Feb 2012 14:46:09 +0100] rev 16103
largefiles: only cache largefiles in new heads This fixes a serious performance regression in largefiles introduced in Mercurial 2.1. Caching new largefiles on pull is necessary, because otherwise largefiles will be missing (and unable to be downloaded) when the user tries to merge or rebase a new head with an old one. But this is an expensive operation and should only be done for heads that are new from the pull, rather than on all heads in the repository.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip