Fri, 05 Jun 2015 21:25:28 +0900 ssl: rename ssl_wrap_socket() to conform to our naming convention
Yuya Nishihara <yuya@tcha.org> [Fri, 05 Jun 2015 21:25:28 +0900] rev 25429
ssl: rename ssl_wrap_socket() to conform to our naming convention I've removed ssl_ prefix because the module name contains ssl.
Fri, 05 Jun 2015 07:49:06 +0900 test-https: kill only hgweb daemon to restart for client-auth test
Yuya Nishihara <yuya@tcha.org> [Fri, 05 Jun 2015 07:49:06 +0900] rev 25428
test-https: kill only hgweb daemon to restart for client-auth test This avoids a test failure on Mac OS X. Because tinyproxy.py isn't detached from the shell, it may complain that a child process is terminated by a signal.
Thu, 04 Jun 2015 17:51:19 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Thu, 04 Jun 2015 17:51:19 -0500] rev 25427
merge with stable
Mon, 01 Jun 2015 18:06:20 -0400 hgwebdir: don't allow the hidden parent of a subrepo to show as a directory stable
Matt Harbison <mharbison@attotech.com> [Mon, 01 Jun 2015 18:06:20 -0400] rev 25426
hgwebdir: don't allow the hidden parent of a subrepo to show as a directory Previously, if a subrepo parent had 'web.hidden=True' set, neither the parent nor child had a repository entry. However, the directory entry for the parent would be listed (it wouldn't have the fancy 'web.name' if configured), and that link went to the repo's summary page, effectively making it not hidden. This simply disables the directory processing if a valid repository is present. Whether or not the subrepo should be hidden is debatable, but this leaves that behavior unchanged (i.e. it stays hidden).
Wed, 03 Jun 2015 14:29:11 -0700 pull: avoid race condition with 'hg pull --rev name --update' (issue4706) stable
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 03 Jun 2015 14:29:11 -0700] rev 25425
pull: avoid race condition with 'hg pull --rev name --update' (issue4706) The previous scheme was: 1) lookup node for all pulled revision, 2) pull said node 3) lookup the node of the checkout target 4) update the repository there. If the remote repo changes between (1) and (3), the resolved name will be different and (3) crash. There is actually no need for a remote lookup during (3), we could just set the value in (1). This prevent the race condition and save a possible network roundtrip.
Fri, 29 May 2015 13:11:52 -0700 revert: add an experimental config to use inverted selection
Laurent Charignon <lcharignon@fb.com> [Fri, 29 May 2015 13:11:52 -0700] rev 25424
revert: add an experimental config to use inverted selection We had a discussion on the list about the interactive ui for revert. This patch adds a flag to allow people to test the second alternative (referred to as proposition 2 on the mailing list). It effectively inverts the signs in the
Wed, 20 May 2015 11:44:06 -0500 bundle2: stop capturing output for ssh again
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 20 May 2015 11:44:06 -0500] rev 25423
bundle2: stop capturing output for ssh again This backout 36111f98f23d since we can have real time output with ssh again. The tests change is not backed-out because it was a test output fix.
Wed, 20 May 2015 11:41:48 -0500 sshpeer: use the doublepipe object for the server to client channel
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 20 May 2015 11:41:48 -0500] rev 25422
sshpeer: use the doublepipe object for the server to client channel This restores real-time output from ssh server while waiting for protocol data sent by the server.
Fri, 22 May 2015 10:48:11 -0500 sshpeer: introduce a "doublepipe" class
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 22 May 2015 10:48:11 -0500] rev 25421
sshpeer: introduce a "doublepipe" class This class is responsible for ensuring we still process the server output streamed through the ssh's 'stderr' pipe during the initial wait for other protocol streams. It currently only works on posix system because of its use of 'select.select'.
Wed, 20 May 2015 18:00:05 -0500 util: add a simple poll utility
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 20 May 2015 18:00:05 -0500] rev 25420
util: add a simple poll utility We'll use it to detect when a sshpeer have server output to be displayed. The implementation is super basic because all case support is not the focus of this series.
Wed, 03 Jun 2015 14:22:21 -0700 crecord: fix blue artifact bug coming back from help screen
Laurent Charignon <lcharignon@fb.com> [Wed, 03 Jun 2015 14:22:21 -0700] rev 25419
crecord: fix blue artifact bug coming back from help screen Before this patch, with record's curses interface: - When one pressed the ? key to see the help menu and then leaves the help menu - Then, blue artifacts would remain on the screen This patch forces a screen clear / refresh after coming back from the help menu. Since we don't have UI test for crecord I checked on my machine that the bug does not reproduce.
Wed, 03 Jun 2015 14:21:15 -0400 scmutil: consistently return subrepos relative to ctx1 from itersubrepos()
Matt Harbison <matt_harbison@yahoo.com> [Wed, 03 Jun 2015 14:21:15 -0400] rev 25418
scmutil: consistently return subrepos relative to ctx1 from itersubrepos() Previously, if a subrepo was added in ctx2 and then compared to another without it (ctx1), the subrepo for ctx2 was returned amongst all of the ctx1 based subrepos, since no subrepo exists in ctx1 to replace it in the 'subpaths' dict. The two callers of this, basectx.status() and cmdutil.diffordiffstat(), both compare the yielded subrepo against ctx2, and thus saw no changes when ctx2's subrepo was returned. The tests here previously didn't mention 's/a' for the 'p1()' case. This appears to have been a known issue, because some diffordiffstat() comments mention that the subpath disappeared, and "the best we can do is ignore it". I originally ran into the issue with some custom convert code to flatten a tree of subrepos causing hg.putcommit() to abort, but this new behavior seems like the correct status and diff behavior regardless. (The abort in convert isn't something users will see, because convert doesn't currently support subrepos in the official repo.)
Wed, 03 Jun 2015 13:51:27 -0400 context: introduce the nullsub() method
Matt Harbison <matt_harbison@yahoo.com> [Wed, 03 Jun 2015 13:51:27 -0400] rev 25417
context: introduce the nullsub() method Ultimately, this will be used by scmutil. The subrepo module already imports it, so it can't import the subrepo module to access the underlying method.
Wed, 03 Jun 2015 13:45:42 -0400 subrepo: introduce the nullsubrepo() method
Matt Harbison <matt_harbison@yahoo.com> [Wed, 03 Jun 2015 13:45:42 -0400] rev 25416
subrepo: introduce the nullsubrepo() method This will be used in an upcoming patch. It's a one-off use, but seems better to be contained in the subrepo module, than for the next patch to overwrite the _ctx and _state fields in another module. '' is used as the default revision in subrepo.state() if it can't be found, so it seems like a safe choice.
Thu, 07 May 2015 17:15:24 +0900 ssl: prompt passphrase of client key file via ui.getpass() (issue4648)
Yuya Nishihara <yuya@tcha.org> [Thu, 07 May 2015 17:15:24 +0900] rev 25415
ssl: prompt passphrase of client key file via ui.getpass() (issue4648) This is necessary to communicate with third-party tools through command-server channel. This requires SSLContext backported to Python 2.7.9+. It doesn't look nice to pass ui by sslkwargs, but I think it is the only way to do without touching various client codes including httpclient (aka http2). ui is mandatory if certfile is specified, so it has no default value. BTW, test-check-commit-hg.t complains that ssl_wrap_socket() has foo_bar naming. Should I bulk-replace it to sslwrapsocket() ?
Thu, 07 May 2015 17:02:20 +0900 https: do not inherit httplib.HTTPSConnection that creates unused SSLContext
Yuya Nishihara <yuya@tcha.org> [Thu, 07 May 2015 17:02:20 +0900] rev 25414
https: do not inherit httplib.HTTPSConnection that creates unused SSLContext HTTPSConnection of Python 2.7.9 creates SSLContext in __init__, which involves a password prompt for decrypting the private key. This means the password was asked twice, one for unused SSLContext, and next for our ssl function. Because our httpsconnection replaces connect() method at all, we can simply drop httplib.HTTPSConnection. Instead, class and instance attributes are copied from it. HTTPSConnection of Python 2.7.8 and 2.6.9 seem to have no such problem. https://hg.python.org/cpython/file/v2.7.9/Lib/httplib.py#l1183
Thu, 07 May 2015 17:38:22 +0900 test-https: test basic functions of client certificate authentication
Yuya Nishihara <yuya@tcha.org> [Thu, 07 May 2015 17:38:22 +0900] rev 25413
test-https: test basic functions of client certificate authentication Because hgweb doesn't support client certificates, I just patched it to require client certificates that are signed and verified by the server certificate. This won't be ideal for production servers, but should be okay for the test. The encrypted key file will be used by future patches. I couldn't figure out a way to redirect a password prompt provided by OpenSSL, so it isn't tested for now.
Mon, 01 Jun 2015 14:16:52 -0400 phases: add `hg help phases` hint to failures to edit public commits
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Mon, 01 Jun 2015 14:16:52 -0400] rev 25412
phases: add `hg help phases` hint to failures to edit public commits There were a couple of locations that were missing this hint after an edition of some kind failed due to the public phase.
Mon, 01 Jun 2015 18:05:38 +0000 phases: rewrite "immutable changeset" to "public changeset"
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Mon, 01 Jun 2015 18:05:38 +0000] rev 25411
phases: rewrite "immutable changeset" to "public changeset" The phrase "cannot edit immutable changeset" is kind of tautological. Of course unchangeable things can't be changed. We instead mention "public" and provide a hint so that we can point to the actual problem. Even in cases where some operation other than edition cannot be performed, "public" gives the root cause that results in the "immutable" effect. There is a precedent for saying "public" instead of "immutable", for example, in `hg commit --amend`.
Tue, 02 Jun 2015 15:04:39 -0400 revlog: raise an exception earlier if an entry is too large (issue4675)
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Tue, 02 Jun 2015 15:04:39 -0400] rev 25410
revlog: raise an exception earlier if an entry is too large (issue4675) Before we were relying on _pack to error out when trying to pass an integer that was too large for the "i" format specifier. Now we check this earlier so we can form a better error message. The error message unfortunately must exclude the filename at this level of the call stack. The problem is that this name is not available here, and the error can be triggered by a large manifest or by a large file itself. Although perhaps we could provide the name of a revlog index file (from the revlog object, instead of the revlogio object), this seems like too much leakage of internal data structures. It's not ideal already that an error message even mentions revlogs, but this does seem unavoidable here.
Wed, 03 Jun 2015 14:31:19 -0500 wix: move library.zip and all *.pyd into a lib/ folder
Steve Borho <steve@borho.org> [Wed, 03 Jun 2015 14:31:19 -0500] rev 25409
wix: move library.zip and all *.pyd into a lib/ folder This makes the root install folder (on Windows) nice and tidy. The only files left in the root folder are: hg.exe python27.dll COPYING.rtf ReadMe.html the last of which was probably out-of-date 7 years ago
Wed, 20 May 2015 11:31:38 -0500 sshpeer: run the ssh command unbuffered
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 20 May 2015 11:31:38 -0500] rev 25408
sshpeer: run the ssh command unbuffered This is necessary to use non-blocking IO base on polling. Such polling is needed to restore real time output with ssh peer. Changeset fce065538bcf is talking about 5x regression on Mac OS X when playing with this value. So we introduced our own buffering layer in previous changesets. This seems to keep the regression away (we are even issuing much less read).
Sun, 31 May 2015 00:00:36 -0700 sshpeer: use a 'bufferedinputpipe' for standard output of the ssh process
Pierre-Yves David <pierre-yves.david@fb.com> [Sun, 31 May 2015 00:00:36 -0700] rev 25407
sshpeer: use a 'bufferedinputpipe' for standard output of the ssh process We need this pipe to still be buffered when will switch to unbuffered pipe. (switch motivated by the need of using polling to restore real time output from ssh server). This is the only pipe that needs to be wrapped because this is the one who do extensive usage of 'readline'. The stderr pipe of the process is alway read in non blocking raw chunk, so it won't benefit from the buffering.
Sat, 30 May 2015 23:55:24 -0700 util: introduce a bufferedinputpipe utility
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 30 May 2015 23:55:24 -0700] rev 25406
util: introduce a bufferedinputpipe utility To restore real time server output through ssh, we need to using polling feature (like select) on the pipes used to communicate with the ssh client. However we cannot use select alongside python level buffering of these pipe (because we need to know if the buffer is non-empty before calling select). However, unbuffered performance are terrible, presumably because the 'readline' call is issuing 'read(1)' call until it find a '\n'. To work around that we introduces our own overlay that do buffering by hand, exposing the state of the buffer to the outside world. The usage of polling IO will be introduced later in the 'sshpeer' module. All its logic will be very specific to the way mercurial communicate over ssh and does not belong to the generic 'util' module.
Wed, 27 May 2015 22:11:37 -0700 test: drop all the forced use of bundle2
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 27 May 2015 22:11:37 -0700] rev 25405
test: drop all the forced use of bundle2 Using bundle2 during exchange is now the default, we do not need all this explicit enabling of bundle2 exchange in test anymore.
Fri, 06 Feb 2015 17:41:24 +0000 bundle2: use bundle2 by default
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 06 Feb 2015 17:41:24 +0000] rev 25404
bundle2: use bundle2 by default All the test change have been isolated and validated. We have free to turn on bundle2 as the default exchange protocol. "To reach a port we must set sail – Sail, not tie at anchor Sail, not drift."
Mon, 01 Jun 2015 10:28:40 -0700 wireprotocol: distinguish list and set in getbundle argument
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 01 Jun 2015 10:28:40 -0700] rev 25403
wireprotocol: distinguish list and set in getbundle argument The 'bundlecaps' argument is expected to be a set, but 'listkeys' is expected to be a list where ordering matters. We introduce a new 'scsv' argument type for the 'set' version and move 'csv' to the 'list' version. 'test-ssh.t' is changed because this introduced an instability in the order we were producing listkeys parts.
Mon, 25 May 2015 17:14:11 -0700 exchange: support transferring .hgtags fnodes mapping
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 25 May 2015 17:14:11 -0700] rev 25402
exchange: support transferring .hgtags fnodes mapping On Mozilla's mozilla-beta repository .hgtags fnodes resolution takes ~18s from a clean cache on my machine. This means that the first time a user runs `hg tags`, `hg log`, or any other command that displays or accesses tags data, a ~18s pause will occur. There is no output during this pause. This results in a poor user experience and perception that Mercurial is slow. The .hgtags changeset to filenode mapping is deterministic. This patch takes advantage of that property by implementing support for transferring .hgtags filenodes mappings in a dedicated bundle2 part. When a client advertising support for the "hgtagsfnodes" capability requests a bundle, a mapping of changesets to .hgtags filenodes will be sent to the client. Only mappings of head changesets included in the bundle will be sent. The transfer of this mapping effectively eliminates one time tags cache related pauses after initial clone. The mappings are sent as binary data. So, 40 bytes per pair of SHA-1s. On the aforementioned mozilla-beta repository, 659 * 40 = 26,360 raw bytes of mappings are sent over the wire (in addition to the bundle part headers). Assuming 18s to populate the cache, we only need to transfer this extra data faster than 1.5 KB/s for overall clone + tags cache population time to be shorter. Put into perspective, the mozilla-beta repository is ~1 GB in size. So, this additional data constitutes <0.01% of the cloned data. The marginal overhead for a multi-second performance win on clones in my opinion justifies an on-by-default behavior.
(0) -10000 -3000 -1000 -300 -100 -50 -28 +28 +50 +100 +300 +1000 +3000 +10000 tip