Wed, 12 Aug 2015 17:01:50 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Wed, 12 Aug 2015 17:01:50 -0500] rev 26014
merge with stable
Tue, 27 Jan 2015 11:26:27 -0800 copy: add flag for disabling copy tracing
Durham Goode <durham@fb.com> [Tue, 27 Jan 2015 11:26:27 -0800] rev 26013
copy: add flag for disabling copy tracing Copy tracing can be up to 80% of rebase time when rebasing stacks of commits in large repos (hundreds of thousands of files). This provides the option of turning off the majority of copy tracing. It does not turn off _forwardcopies() since that is used to carry copy information inside a commit across a rebase. This will affect the situation where a user edits a file, then rebases on top of commits that have moved that file. The move will not be detected and the user will have to manually resolve the issue (possibly by redoing the rebase with this flag off). The reason to have a flag instead of trying to fix the actual copy tracing performance is that copy tracing is fundamentally an O(number of files in the repo) operation. In order to know if file X in the rebase source was copied anywhere, we have to walk the filelog for every new file that exists in the rebase destination (i.e. a file in the destination that is not in the common ancestor). Without an index that lets us trace forward (i.e. from file Y in the common ancestor forward to the rebase destination), it will never be an O(number of changes in my branch) operation. In mozilla-central, rebasing a 3 commit stack across 20,000 revs goes from 39s to 11s.
Sat, 08 Aug 2015 14:50:03 -0700 strip: use the 'finally: tr.release' pattern during stripping stable
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 08 Aug 2015 14:50:03 -0700] rev 26012
strip: use the 'finally: tr.release' pattern during stripping The previous code, was calling 'abort' in all exception cases. This was wrong when an exception was raised by post-close callback on the transaction. Calling 'abort' on an already closed transaction resulted in a error, shadowing the original error. We now use the same pattern as everywhere else. 'tr.release()' will abort the transaction if we escape the scope without closing it. We add a test to make sure we do not regress.
Tue, 11 Aug 2015 15:06:02 -0400 changelog: trust C implementation of reachableroots more
Augie Fackler <augie@google.com> [Tue, 11 Aug 2015 15:06:02 -0400] rev 26011
changelog: trust C implementation of reachableroots more There are no remaining codepaths in reachableroots where it will return None, so just trust it completely and simplify this method. Result by revset ================ Revision: 0) Revision 1c75249e159b: style: adjust whitespaces in webutil.py 1) Revision d1d91b8090c6: changelog: trust C implementation of reachableroots more revset #0: 0::tip plain 0) 0.067684 1) 0.006622 9% revset #1: 0::@ plain 0) 0.068249 1) 0.009394 13% IOW this is a 10x speedup in my repo for hg itself for 0::tip and similar revsets now that the C code is correctly wired up.
Tue, 11 Aug 2015 14:53:47 -0400 reachableroots: return NULL if we're throwing an exception
Augie Fackler <augie@google.com> [Tue, 11 Aug 2015 14:53:47 -0400] rev 26010
reachableroots: return NULL if we're throwing an exception Based on my reading of [0] and surrounding sections, if we want an exception to be properly raised when something goes wrong in the C code, we need to make sure we return NULL here. Do so. https://docs.python.org/2/extending/extending.html#back-to-the-example
Tue, 11 Aug 2015 15:34:10 -0400 reachableroots: fix transposition of set and list types in PyArg_ParseTuple
Augie Fackler <augie@google.com> [Tue, 11 Aug 2015 15:34:10 -0400] rev 26009
reachableroots: fix transposition of set and list types in PyArg_ParseTuple This is being masked by the function not properly returning NULL when it raises an exception, so the client code was just falling back to the native codepath when it got None back. A future change removes all reason for this C function to return None, which exposed this problem during development.
Tue, 11 Aug 2015 14:50:39 -0400 reachableroots: consistently use short-form of PyErr_NoMemory()
Augie Fackler <augie@google.com> [Tue, 11 Aug 2015 14:50:39 -0400] rev 26008
reachableroots: consistently use short-form of PyErr_NoMemory()
Tue, 11 Aug 2015 14:49:40 -0400 reachableroots: if allocating a new set fails, use PyErr_NoMemory()
Augie Fackler <augie@google.com> [Tue, 11 Aug 2015 14:49:40 -0400] rev 26007
reachableroots: if allocating a new set fails, use PyErr_NoMemory() My inspection of the implementation of PySet_New() indicates that it does *not* reliably set an exception in the cases where it returns NULL (as far as I can tell it'll never do that!), so let's set that up ourselves.
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.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip