Matt Mackall <mpm@selenic.com> [Wed, 12 Aug 2015 17:01:50 -0500] rev 26014
merge with stable
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.
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.
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.
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
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.
Augie Fackler <augie@google.com> [Tue, 11 Aug 2015 14:50:39 -0400] rev 26008
reachableroots: consistently use short-form of 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.
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.
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.