Sat, 10 Jun 2017 18:04:56 +0900 revset: fix order of last() n members where n > 1 (BC)
Yuya Nishihara <yuya@tcha.org> [Sat, 10 Jun 2017 18:04:56 +0900] rev 32817
revset: fix order of last() n members where n > 1 (BC) last() is implemented using a reversed iterator, so the result should be reversed again. I've marked this as BC since it's quite old bug seen in 3.0. The first bad revision is 4849f574aa24 "revset: changed last implementation to use lazy classes."
Sat, 10 Jun 2017 20:14:23 +0900 debugrevspec: add option to suppress list of computed revisions
Yuya Nishihara <yuya@tcha.org> [Sat, 10 Jun 2017 20:14:23 +0900] rev 32816
debugrevspec: add option to suppress list of computed revisions Test will be added later.
Sat, 10 Jun 2017 20:03:35 +0900 debugrevspec: add option to print representation of smartset object
Yuya Nishihara <yuya@tcha.org> [Sat, 10 Jun 2017 20:03:35 +0900] rev 32815
debugrevspec: add option to print representation of smartset object It's possible by -v, but -v also prints a parsed tree. Test will be added later.
Sat, 10 Jun 2017 01:59:22 +0100 bookmarks: make sure we close the bookmark file after reading
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 10 Jun 2017 01:59:22 +0100] rev 32814
bookmarks: make sure we close the bookmark file after reading We previously lacked an explicit close of the bookmark file.
Sat, 10 Jun 2017 01:55:01 +0100 bookmarks: rephrase a comment to be shorted and clearer
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 10 Jun 2017 01:55:01 +0100] rev 32813
bookmarks: rephrase a comment to be shorted and clearer The initial motivation is that I need an initial level of indent in the next changeset o:-) It turn out I like the new version better.
Mon, 05 Jun 2017 13:44:15 +0100 checkheads: use a "lazyancestors" object for allfuturecommon
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 05 Jun 2017 13:44:15 +0100] rev 32812
checkheads: use a "lazyancestors" object for allfuturecommon Instead of walking all ancestors to compute the full set we now check membership lazily. This massively speed. On a million-ish revision repository, this remove 14 seconds from the push logic, making the checkheads function disappear from profile.
Mon, 05 Jun 2017 13:37:04 +0100 checkheads: use "revnum" in the "allfuturecommon" set
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 05 Jun 2017 13:37:04 +0100] rev 32811
checkheads: use "revnum" in the "allfuturecommon" set The obsolete post-processing needs to know the extend of the pushed set. The way it is implemented is... suboptimal. It build a full set of all nodes in the pushset and it does so using changectx. We have much better API for this now. The simplest is to use the existing lazy ancestors computation. That logic uses revnum and not node (for good reason) so we start with updating the post-processing code to handle a "allfuturecommon" set containing revision numbers.
Mon, 05 Jun 2017 15:20:20 +0100 checkheads: use 'nodemap.get' to convert nodes to revs
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 05 Jun 2017 15:20:20 +0100] rev 32810
checkheads: use 'nodemap.get' to convert nodes to revs We are about to call 'torev' on node that might be locally missing. In this case, 'nodemap.revs' will return None (something valid in our usecase) while 'changelog.rev' would raise an exception. We make this change in a distinct changeset to show it does not impact the tests.
Mon, 05 Jun 2017 15:17:47 +0100 checkheads: pass "ispushed" function to the obsmarkers logic
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 05 Jun 2017 15:17:47 +0100] rev 32809
checkheads: pass "ispushed" function to the obsmarkers logic We are about to make "allfuturecommon" a set of revs instead of a set of nodes. The function updated in this patch do not needs to know about these details so we just pass it a 'ispushed(node)' function. This will simplify the next changeset.
Fri, 09 Jun 2017 12:29:29 +0100 profile: drop maybeprofile
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 09 Jun 2017 12:29:29 +0100] rev 32808
profile: drop maybeprofile It seems sufficiently simple to use "profile(enabled=X)" to not justify having a dedicated context manager just to read the config. (I do not have a too strong opinion about this).
Fri, 09 Jun 2017 12:36:07 +0100 profile: support --profile in alias and abbreviated version (--prof)
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 09 Jun 2017 12:36:07 +0100] rev 32807
profile: support --profile in alias and abbreviated version (--prof) We now process the "--profile" a second time after alias has been processed and the command argument fully parsed. If appropriate we enable profiling at that time. In these situation, the --profile will cover less than if the full --profile flag was passed on the command line. This is better than the previous behavior (flag ignored) and still fullfil multiple valid usecases.
Fri, 09 Jun 2017 11:42:45 +0100 profile: make the contextmanager object available to the callers
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 09 Jun 2017 11:42:45 +0100] rev 32806
profile: make the contextmanager object available to the callers This will allow calling methods on the object in the code using the context manager.
Fri, 09 Jun 2017 11:41:47 +0100 profile: introduce a knob to control if the context is actually profiling
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 09 Jun 2017 11:41:47 +0100] rev 32805
profile: introduce a knob to control if the context is actually profiling This is a step toward allowing context where the profiling in enabled withing the context range. This also open the way to kill the dedicated "maybeprofile" context manager and keep only one of 'profile' and 'maybeprofile'.
Fri, 09 Jun 2017 11:39:53 +0100 profile: introduce a "start" method to the profile context
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 09 Jun 2017 11:39:53 +0100] rev 32804
profile: introduce a "start" method to the profile context The start method is doing all profiler setup and activation. It is currently unconditionally called by '__init__' but this will be made more flexible in later changesets.
(0) -30000 -10000 -3000 -1000 -300 -100 -14 +14 +100 +300 +1000 +3000 +10000 tip