Mon, 05 Jan 2015 15:46:14 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Mon, 05 Jan 2015 15:46:14 -0600] rev 23726
merge with stable
Mon, 05 Jan 2015 11:02:04 +0900 revset: delay showing parse error for the revset alias until it is referred
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 05 Jan 2015 11:02:04 +0900] rev 23725
revset: delay showing parse error for the revset alias until it is referred Before this patch, a problematic revset alias aborts execution immediately, even if it isn't referred in the specified revset. If old "hg" may be used too (for example, bisecting Mercurial itself), it is also difficult to write alias definitions using features newly introduced by newer "hg" into configuration files, because such alias definitions cause unexpected abortion at parsing revset aliases with old "hg". This patch delays showing parse error for the revset alias until it is actually referred at runtime. This patch detects referring problematic aliases in "_expandaliases" by examination of "revsetalias.error", which is initialized with the error message only when parsing fails. For usability, this patch also warns about problematic aliases, even if they aren't referred at runtime. This should help users to know potential problems in their alias definitions earlier.
Sat, 03 Jan 2015 10:25:08 +0900 revset: drop pre-lazyset optimization for stringset of subset == entire repo stable
Yuya Nishihara <yuya@tcha.org> [Sat, 03 Jan 2015 10:25:08 +0900] rev 23724
revset: drop pre-lazyset optimization for stringset of subset == entire repo It was introduced at e44ebd2a142a, where spanset.__contains__() did not exist. Nowadays, we have to pay huge penalty for len(subset). The following example showed that OR operation could be O(n * m^2) (n: len(repo), m: number of OR operators, m >= 2) probably because of filteredset.__len__. revset #0: 0|1|2|3|4|5|6|7|8|9 0) wall 8.092713 comb 8.090000 user 8.090000 sys 0.000000 (best of 3) 1) wall 0.445354 comb 0.450000 user 0.430000 sys 0.020000 (best of 22) 2) wall 0.000389 comb 0.000000 user 0.000000 sys 0.000000 (best of 7347) (0: 3.2.4, 1: 3.1.2, 2: this patch)
Sat, 03 Jan 2015 11:12:44 +0000 keyword: update copyright year
Christian Ebert <blacktrash@gmx.net> [Sat, 03 Jan 2015 11:12:44 +0000] rev 23723
keyword: update copyright year
Sat, 03 Jan 2015 11:11:46 +0000 keyword: use vfs.reljoin and util.unlinkpath to remove kwdemo
Christian Ebert <blacktrash@gmx.net> [Sat, 03 Jan 2015 11:11:46 +0000] rev 23722
keyword: use vfs.reljoin and util.unlinkpath to remove kwdemo
Sun, 04 Jan 2015 15:26:26 -0500 largefiles: properly sync lfdirstate after removing largefiles stable
Matt Harbison <matt_harbison@yahoo.com> [Sun, 04 Jan 2015 15:26:26 -0500] rev 23721
largefiles: properly sync lfdirstate after removing largefiles The more aggressive synchronization of lfdirstate that was backed out in 1265a3a71d75 masked the problem where lfdirstate would hold an 'R' for a largefile that was added and then removed without a commit between. We could just conditionally call lfdirstate.drop() or lfdirstate.remove() here, but this also properly updates lfdirstate if the standin doesn't exist for the file somehow (i.e. call drop instead of remove). Without this change, the precommit status in the commit command immediately after the test change lists the removed (and never committed) largefile as 'R'. It can also lead to situations where the status command reports the same, long after the commit [1]. [1] http://www.selenic.com/pipermail/mercurial-devel/2015-January/065153.html
Mon, 29 Dec 2014 18:35:23 -0800 linkrev-filelog: handle filtered linkrev with no visible children (issue4307)
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 29 Dec 2014 18:35:23 -0800] rev 23720
linkrev-filelog: handle filtered linkrev with no visible children (issue4307) If the file revision with a filtered linkrev does not have any (unfiltered) children, we cannot use it to bound the search for another introduction. Instead, we have to look at the file revision used by each head changeset. If one of them uses this file revision, we know there is another occurrence and we have a starting point. See inline comments for details. Adding some kind of permanent reference of all the introductions of a file revision instead of just the first one would be much better. But this is more difficult. I hope to take that into account in the next repository format.
Mon, 29 Dec 2014 17:23:16 -0800 linkrev: work around linkrev to filtered entry in 'filelog' revset
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 29 Dec 2014 17:23:16 -0800] rev 23719
linkrev: work around linkrev to filtered entry in 'filelog' revset This revset is used by 'hg log FILENAME'. This prevent bugs when used on a repository with hidden revisions. Instead of just discarding file revisions whose linkrevs point to filtered revisions, we put them aside and post-process them trying to find a non-filtered introduction. See inline documentation for details about how it works. This only fixes some of the problems. Once again, more will be needed when we can cannot rely on child revisions of a file to find linkrev-shadowned revisions. A test is added for 'hg log' catching such cases.
Sun, 21 Dec 2014 13:06:24 -0800 namespaces: update documentation and code indentation
Sean Farley <sean.michael.farley@gmail.com> [Sun, 21 Dec 2014 13:06:24 -0800] rev 23718
namespaces: update documentation and code indentation The previous patch changed just the functionality, while this patch focuses on the documentation and indentation to keep review simple.
Fri, 19 Dec 2014 17:27:20 -0800 namespaces: use namespace object instead of dictionary
Sean Farley <sean.michael.farley@gmail.com> [Fri, 19 Dec 2014 17:27:20 -0800] rev 23717
namespaces: use namespace object instead of dictionary This isn't as bad as the diff seems, it only looks like scary. In this patch, we use the 'namespace' object instead of accessing keys in a dictionary. This required the 'templatename' and 'names' method to change their implementation. Later, we will remove these functions entirely due to a better api.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip