Dirkjan Ochtman <dirkjan@ochtman.nl> [Thu, 21 Feb 2008 15:56:35 +0100] rev 6155
hgweb: no i18n in protocol responses
Dirkjan Ochtman <dirkjan@ochtman.nl> [Thu, 21 Feb 2008 17:02:28 +0100] rev 6154
improve changegroup.readbundle(), use it in hgweb
Stefan Rank <strank(AT)strank(DOT)info> [Wed, 20 Feb 2008 21:31:42 +0100] rev 6153
Also search for .hgrc if mercurial.ini not found on windows
Dirkjan Ochtman <dirkjan@ochtman.nl> [Thu, 21 Feb 2008 15:00:25 +0100] rev 6152
hgweb: use bundletypes from mercurial.changegroup
Bryan O'Sullivan <bos@serpentine.com> [Wed, 20 Feb 2008 13:38:16 -0800] rev 6151
Merge with crew
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.
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).
Alexis S. L. Carvalho <alexis@cecm.usp.br> [Tue, 19 Feb 2008 19:34:18 -0300] rev 6148
update output of test-convert
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
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.