Wed, 20 Feb 2008 13:38:16 -0800 Merge with crew
Bryan O'Sullivan <bos@serpentine.com> [Wed, 20 Feb 2008 13:38:16 -0800] rev 6151
Merge with crew
Fri, 25 Jan 2008 04:11:32 -0500 Infer a --repository argument from command arguments when reasonable.
Jesse Glick <jesse.glick@sun.com> [Fri, 25 Jan 2008 04:11:32 -0500] rev 6150
Infer a --repository argument from command arguments when reasonable. In particular: if invoked without -R from a CWD not inside a repo, having been passed one or more file paths as command arguments, where the nearest enclosing repo of all of those paths is the same, quietly infer a -R option for that repo. Otherwise abort with an error message as before.
Wed, 20 Feb 2008 10:50:10 +0100 hgweb: separate protocol calls from interface calls (issue996)
Dirkjan Ochtman <dirkjan@ochtman.nl> [Wed, 20 Feb 2008 10:50:10 +0100] rev 6149
hgweb: separate protocol calls from interface calls (issue996) The protocol functions are already pretty careful about not raising exceptions to the caller, and have their own error handling. We can formalize this a little bit to make it clearer (before, the exception handlers for a limited number of exceptions coming from the interface bits would blow up because some variables aren't instantiated for the protocol calls).
Tue, 19 Feb 2008 19:34:18 -0300 update output of test-convert
Alexis S. L. Carvalho <alexis@cecm.usp.br> [Tue, 19 Feb 2008 19:34:18 -0300] rev 6148
update output of test-convert
Tue, 19 Feb 2008 19:20:10 -0300 repair.py: rewrite a loop, making it cleaner and faster
Alexis S. L. Carvalho <alexis@cecm.usp.br> [Tue, 19 Feb 2008 19:20:10 -0300] rev 6147
repair.py: rewrite a loop, making it cleaner and faster
Tue, 19 Feb 2008 19:20:10 -0300 Speed up hg grep by avoiding useless manifest parsing
Alexis S. L. Carvalho <alexis@cecm.usp.br> [Tue, 19 Feb 2008 19:20:10 -0300] rev 6146
Speed up hg grep by avoiding useless manifest parsing In the kernel repo (tip = 2b89f7111b96), a "hg grep mpm MAINTAINERS" goes from ~165s to 0.7s. This could get even a bit faster if we broke out of the loop after the first match, but I'm not sure how that would interact with the --follow code. This is obviously an extreme example, but other cases should also benefit from this patch.
(0) -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip