Fri, 15 Nov 2013 23:18:08 -0500 branchmap: add documentation on the branchcache on-disk format
Brodie Rao <brodie@sf.io> [Fri, 15 Nov 2013 23:18:08 -0500] rev 20181
branchmap: add documentation on the branchcache on-disk format
Sun, 17 Nov 2013 18:04:29 -0500 revlog: allow tuning of the chunk cache size (via format.chunkcachesize)
Brodie Rao <brodie@sf.io> [Sun, 17 Nov 2013 18:04:29 -0500] rev 20180
revlog: allow tuning of the chunk cache size (via format.chunkcachesize) Running perfmoonwalk on the Mercurial repo (with almost 20,000 changesets) on Mac OS X with an SSD, before this change: $ hg --config format.chunkcachesize=1024 perfmoonwalk ! wall 2.022021 comb 2.030000 user 1.970000 sys 0.060000 (best of 5) (16,154 cache hits, 3,840 misses.) $ hg --config format.chunkcachesize=4096 perfmoonwalk ! wall 1.901006 comb 1.900000 user 1.880000 sys 0.020000 (best of 6) (19,003 hits, 991 misses.) $ hg --config format.chunkcachesize=16384 perfmoonwalk ! wall 1.802775 comb 1.800000 user 1.800000 sys 0.000000 (best of 6) (19,746 hits, 248 misses.) $ hg --config format.chunkcachesize=32768 perfmoonwalk ! wall 1.818545 comb 1.810000 user 1.810000 sys 0.000000 (best of 6) (19,870 hits, 124 misses.) $ hg --config format.chunkcachesize=65536 perfmoonwalk ! wall 1.801350 comb 1.810000 user 1.800000 sys 0.010000 (best of 6) (19,932 hits, 62 misses.) $ hg --config format.chunkcachesize=131072 perfmoonwalk ! wall 1.805879 comb 1.820000 user 1.810000 sys 0.010000 (best of 6) (19,963 hits, 31 misses.) We may want to change the default size in the future based on testing and user feedback.
Sun, 17 Nov 2013 18:04:28 -0500 revlog: read/cache chunks in fixed windows of 64 KB
Brodie Rao <brodie@sf.io> [Sun, 17 Nov 2013 18:04:28 -0500] rev 20179
revlog: read/cache chunks in fixed windows of 64 KB When reading a revlog chunk, instead of reading up to 64 KB ahead of the request offset and caching that, this change caches a fixed window before and after the requested data that falls on 64 KB boundaries. This increases cache hits when reading revlogs backwards. Running perfmoonwalk on the Mercurial repo (with almost 20,000 changesets) on Mac OS X with an SSD, before this change: $ hg perfmoonwalk ! wall 2.307994 comb 2.310000 user 2.120000 sys 0.190000 (best of 5) (Each run has 10,668 cache hits and 9,304 misses.) After this change: $ hg perfmoonwalk ! wall 1.814117 comb 1.810000 user 1.810000 sys 0.000000 (best of 6) (19,931 cache hits, 62 misses.) On a busy NFS share, before this change: $ hg perfmoonwalk ! wall 17.000034 comb 4.100000 user 3.270000 sys 0.830000 (best of 3) After: $ hg perfmoonwalk ! wall 1.746115 comb 1.670000 user 1.660000 sys 0.010000 (best of 5)
Sun, 17 Nov 2013 18:04:28 -0500 perf: add perfmoonwalk command to walk the changelog backwards
Brodie Rao <brodie@sf.io> [Sun, 17 Nov 2013 18:04:28 -0500] rev 20178
perf: add perfmoonwalk command to walk the changelog backwards This lets us test the effectiveness (or ineffectiveness) of the revlog chunk cache when walking revlogs backwards.
Tue, 03 Dec 2013 13:28:04 -0500 largefiles: call super class method with proper kwargs to respect API
Long Vu <long@tlvu.ca> [Tue, 03 Dec 2013 13:28:04 -0500] rev 20177
largefiles: call super class method with proper kwargs to respect API Since the localrepositoyry.push() method in mercurial/localrepo.py is defined this way: def push(self, remote, force=False, revs=None, newbranch=False): it is better for largefiles to call push() on the super class with proper kwargs to respect the API. This will avoid breaking other extensions overriding the push method this way: def push(self, remote, force=False, **kwargs):
Wed, 13 Nov 2013 15:55:30 +0900 subrepo: check phase of state in each subrepositories before committing
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 13 Nov 2013 15:55:30 +0900] rev 20176
subrepo: check phase of state in each subrepositories before committing Before this patch, phase of newly created commit is determined by "phases.new-commit" configuration regardless of phase of state in each subrepositories. For example, this may cause the "public" revision in the parent repository referring the "secret" one in subrepository. This patch checks phase of state in each subrepositories before committing in the parent, and aborts or changes phase of newly created commit if subrepositories have more restricted phase than the parent. This patch uses "follow" as default value of "phases.checksubrepos" configuration, because it can keep consistency between phases of the parent and subrepositories without breaking existing tool chains.
Mon, 16 Dec 2013 12:59:32 -0600 merge with crew
Matt Mackall <mpm@selenic.com> [Mon, 16 Dec 2013 12:59:32 -0600] rev 20175
merge with crew
Sat, 14 Dec 2013 12:48:12 -0500 http: backout 181108726ea5, which breaks on Python 2.4
Augie Fackler <raf@durin42.com> [Sat, 14 Dec 2013 12:48:12 -0500] rev 20174
http: backout 181108726ea5, which breaks on Python 2.4
Sat, 14 Dec 2013 11:58:26 -0500 test-module-imports: try and detect virtualenv breakage (issue4129)
Augie Fackler <raf@durin42.com> [Sat, 14 Dec 2013 11:58:26 -0500] rev 20173
test-module-imports: try and detect virtualenv breakage (issue4129) virtualenvs (among other things) break the stdlib module detection in the import checker, and I don't see a good way to work around that for now.
Mon, 25 Nov 2013 17:18:12 +0100 http: reuse authentication info after the first failed request (issue3567)
Stéphane Klein <contact@stephane-klein.info> [Mon, 25 Nov 2013 17:18:12 +0100] rev 20172
http: reuse authentication info after the first failed request (issue3567) Context: mercurial access to repository server with http access, and this server is protected by basic auth. Before patch: * mercurial try an anonymous access to server, server return 401 response and mercurial resend request with login / password information After patch: * mercurial try an anonymous access to server, server return 401 response. For all subsequent requests, mercurial keep in memory this information (this server need basic auth information). This patch reduce the number of http access against mercurial server. Example, before patch : 10.10.168.170 - - [25/Oct/2013:15:44:51 +0200] "GET /hg/testagt?cmd=capabilities HTTP/1.1" 401 260 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:44:52 +0200] "GET /hg/testagt?cmd=capabilities HTTP/1.1" 200 147 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:45:00 +0200] "GET /hg/testagt?cmd=capabilities HTTP/1.1" 401 260 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:45:01 +0200] "GET /hg/testagt?cmd=capabilities HTTP/1.1" 200 147 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:45:03 +0200] "GET /hg/testagt?cmd=batch HTTP/1.1" 401 260 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:45:04 +0200] "GET /hg/testagt?cmd=batch HTTP/1.1" 200 42 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:45:06 +0200] "GET /hg/testagt?cmd=getbundle HTTP/1.1" 401 260 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:45:07 +0200] "GET /hg/testagt?cmd=getbundle HTTP/1.1" 200 61184 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:45:09 +0200] "GET /hg/testagt?cmd=listkeys HTTP/1.1" 401 260 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:45:10 +0200] "GET /hg/testagt?cmd=listkeys HTTP/1.1" 200 15 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:45:12 +0200] "GET /hg/testagt?cmd=listkeys HTTP/1.1" 401 260 "-" "mercurial/proto-1.0" 10.10.168.170 - - [25/Oct/2013:15:45:12 +0200] "GET /hg/testagt?cmd=listkeys HTTP/1.1" 200 - "-" "mercurial/proto-1.0" Example after patch : 10.10.168.170 - - [28/Oct/2013:11:49:14 +0100] "GET /hg/testagt?cmd=capabilities HTTP/1.1" 401 260 "-" "mercurial/proto-1.0" 10.10.168.170 - - [28/Oct/2013:11:49:15 +0100] "GET /hg/testagt?cmd=capabilities HTTP/1.1" 200 147 "-" "mercurial/proto-1.0" 10.10.168.170 - - [28/Oct/2013:11:49:17 +0100] "GET /hg/testagt?cmd=batch HTTP/1.1" 200 42 "-" "mercurial/proto-1.0" 10.10.168.170 - - [28/Oct/2013:11:49:19 +0100] "GET /hg/testagt?cmd=getbundle HTTP/1.1" 200 61184 "-" "mercurial/proto-1.0" 10.10.168.170 - - [28/Oct/2013:11:49:22 +0100] "GET /hg/testagt?cmd=listkeys HTTP/1.1" 200 15 "-" "mercurial/proto-1.0" 10.10.168.170 - - [28/Oct/2013:11:49:24 +0100] "GET /hg/testagt?cmd=listkeys HTTP/1.1" 200 - "-" "mercurial/proto-1.0" In this last example, you can see only one 401 response.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip