Thu, 06 Aug 2015 22:11:20 -0700 reachableroots: default to the C implementation
Laurent Charignon <lcharignon@fb.com> [Thu, 06 Aug 2015 22:11:20 -0700] rev 26006
reachableroots: default to the C implementation This patch is part of a series of patches to speed up the computation of revset.reachableroots by introducing a C implementation. The main motivation is to speed up smartlog on big repositories. At the end of the series, on our big repositories the computation of reachableroots is 10-50x faster and smartlog on is 2x-5x faster. Before this patch, reachableroots was computed in pure Python by default. This patch makes the C implementation the default and provides a speedup for reachableroots.
Thu, 06 Aug 2015 22:10:31 -0700 changelog: add way to call the reachableroots C implementation
Laurent Charignon <lcharignon@fb.com> [Thu, 06 Aug 2015 22:10:31 -0700] rev 26005
changelog: add way to call the reachableroots C implementation This patch is part of a series of patches to speed up the computation of revset.reachableroots by introducing a C implementation. The main motivation is to speed up smartlog on big repositories. At the end of the series, on our big repositories the computation of reachableroots is 10-50x faster and smartlog on is 2x-5x faster. This patch allows us to call the new C implementation of reachableroots from python by creating an entry point in the changelog class.
Thu, 06 Aug 2015 21:28:45 -0700 reachableroots: add a C implementation
Laurent Charignon <lcharignon@fb.com> [Thu, 06 Aug 2015 21:28:45 -0700] rev 26004
reachableroots: add a C implementation This patch is part of a series of patches to speed up the computation of revset.reachableroots by introducing a C implementation. The main motivation is to speed up smartlog on big repositories. At the end of the series, on our big repositories the computation of reachableroots is 10-50x faster and smartlog on is 2x-5x faster. This patch introduces a C implementation for reachableroots following closely the Python implementation but optimized by using C data structures.
Fri, 19 Jun 2015 20:28:52 -0700 revset: remove grandparent by using reachableroots
Laurent Charignon <lcharignon@fb.com> [Fri, 19 Jun 2015 20:28:52 -0700] rev 26003
revset: remove grandparent by using reachableroots This patch is part of a series of patches to speed up the computation of revset.reachableroots by introducing a C implementation. The main motivation is to speed up smartlog on big repositories. At the end of the series, on our big repositories the computation of reachableroots is 10-50x faster and smartlog on is 2x-5x faster. Before this patch, we had a custom computation for grandparent that was very close to the idea of reacheablerooots. This patch expresses grandparent with reachableroots to reduce the amount of code.
Fri, 19 Jun 2015 20:18:54 -0700 revset: rename revsbetween to reachableroots and add an argument
Laurent Charignon <lcharignon@fb.com> [Fri, 19 Jun 2015 20:18:54 -0700] rev 26002
revset: rename revsbetween to reachableroots and add an argument This patch is part of a series of patches to speed up the computation of revset.revsbetween by introducing a C implementation. The main motivation is to speed up smartlog on big repositories. At the end of the series, on our big repositories the computation of revsbetween is 10-50x faster and smartlog on is 2x-5x faster. This patch rename 'revsbetween' to 'reachableroots' and makes the computation of the full path optional. This will allow graphlog to compute grandparents using 'reachableroots' and remove the need for a dedicated grandparent function.
Fri, 07 Aug 2015 02:13:42 -0700 revset: make revsbetween public
Laurent Charignon <lcharignon@fb.com> [Fri, 07 Aug 2015 02:13:42 -0700] rev 26001
revset: make revsbetween public This patch is part of a series of patches to speed up the computation of revset.revsbetween by introducing a C implementation. The main motivation is to speed up smartlog on big repositories. At the end of the series, on our big repositories the computation of revsbetween is 10-50x faster and smartlog on is 2x-5x faster. Later in this serie, we want to reuse the implementation of revsbetween in the changelog module, therefore, we make it public.
Thu, 06 Aug 2015 21:00:16 -0400 match: fix a caseonly rename + explicit path commit on icasefs (issue4768) stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 06 Aug 2015 21:00:16 -0400] rev 26000
match: fix a caseonly rename + explicit path commit on icasefs (issue4768) The problem was that the former name and the new name are both normalized to the case in dirstate, so matcher._files would be ['ABC.txt', 'ABC.txt']. localrepo.commit() calls localrepo.status(), passing along the matcher. Inside dirstate.status(), _walkexplicit() simply grabs matcher.files() and processes those items. Since the old name isn't present, it is silently dropped. There's a fundamental tension here, because the status command should also accept files that don't match the filesystem, so we can't drop the normalization in status. The problem originated in baa11dde8c0e. Unfortunately with this change, the case of the old file must still be specified exactly, or the old file is again silently excluded. I went back to baa11dde8c0e^, and that had the same behavior, so we are no worse off. I'm open to ideas from a matcher or dirstate expert on how to fix that half.
Tue, 11 Aug 2015 13:19:42 +0800 style: adjust whitespaces in webutil.py
Anton Shestakov <av6@dwimlabs.net> [Tue, 11 Aug 2015 13:19:42 +0800] rev 25999
style: adjust whitespaces in webutil.py Turns out, all this came from the single d605a82cf189.
Mon, 10 Aug 2015 15:30:28 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Mon, 10 Aug 2015 15:30:28 -0500] rev 25998
merge with stable
Thu, 06 Aug 2015 17:21:46 -0700 convert: fix git copy file content conversions stable
Durham Goode <durham@fb.com> [Thu, 06 Aug 2015 17:21:46 -0700] rev 25997
convert: fix git copy file content conversions There was a bug in the git convert code where if you copied a file and modified the copy source in the same commit, and if the copy dest was alphabetically earlier than the copy source, the converted version would use the copy dest contents for both the source and the target. The root of the bug is that the git diff-tree output is formatted like so: :<mode> <mode> <oldhash> <newhash> <state> <src> <dest> :100644 100644 c1ab79a15... 3dfc779ab... C069 oldname newname :100644 100644 c1ab79a15... 03e2188a6... M oldname The old code would always take the 'oldname' field as the name of the file being processed, then it would try to do an extra convert for the newname. This works for renames because it does a delete for the oldname and a create for the newname. For copies though, it ends up associating the copied content (3dfc779ab above) with the oldname. It only happened when the dest was alphabetically before because that meant the copy got processed before the modification. The fix is the treat copy lines as affecting only the newname, and not marking the oldname as processed.
Sun, 09 Aug 2015 16:09:41 +0900 revset: prevent crash caused by empty group expression while optimizing "or" stable
Yuya Nishihara <yuya@tcha.org> [Sun, 09 Aug 2015 16:09:41 +0900] rev 25996
revset: prevent crash caused by empty group expression while optimizing "or" An empty group expression "()" generates None in AST, so it should be tested before destructuring a tuple. "A | ()" is still evaluated to an error because I'm not sure whether "()" represents an empty set or an empty expression (= a unit value). They are identical in "or" operation, but they should be evaluated differently in "and" operation. expression empty set unit value ---------- --------- ---------- () {} A A & () {} A A | () A A
Sun, 09 Aug 2015 16:06:36 +0900 revset: prevent crash caused by empty group expression while optimizing "and" stable
Yuya Nishihara <yuya@tcha.org> [Sun, 09 Aug 2015 16:06:36 +0900] rev 25995
revset: prevent crash caused by empty group expression while optimizing "and" An empty group expression "()" generates None in AST, so the optimizer have to test it before destructuring a tuple. The error message, "missing argument", is somewhat obscure, but it should be better than crash.
(0) -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 +3000 +10000 tip