f29cab5c519ca546b1796eb2a874367024795f01: hghave: change ssl check to just check ssl module
Gregory Szorc <gregory.szorc@gmail.com> - Sat, 19 Mar 2016 13:51:00 -0700 - rev 30901
Push 209 by gszorc@mozilla.com at Sun, 27 Mar 2016 04:36:25 +0000
hghave: change ssl check to just check ssl module Previously, the "ssl" check effectively looked for PyOpenSSL or Python 2.7.9. After this patch, we simply look for just the "ssl" module. After d962e955da08, there have been no references to PyOpenSSL in the tree (the previous usage of PyOpenSSL was to implement ssl support on old, no longer supported Python versions that didn't have an ssl module (e.g. Python 2.4). So, the check for PyOpenSSL served no purpose. Pythons we support ship with the ssl module. Although it may not be available in all installations. So, we still need the check for whether the ssl module imports, hence the hghave check. The main side-effect of this change is that we now run test-https.t (the only test requiring the "ssl" hghave feature) on Python <2.7.9 when PyOpenSSL is not installed (which is probably most installations) and the ssl module is available. Before, we wouldn't run this test on these older Python versions. I confirmed that test-https.t passes with Python 2.6.9 and 2.7.8 on OS X 10.11.
b0b9f6b0a7773e200f264664af61795ccfc1c3c5: help: document sharing of revlog header with revision 0
Gregory Szorc <gregory.szorc@gmail.com> - Sat, 19 Mar 2016 15:17:33 -0700 - rev 30900
Push 209 by gszorc@mozilla.com at Sun, 27 Mar 2016 04:36:25 +0000
help: document sharing of revlog header with revision 0 The previous docs were incorrect about there being a discrete header on revlogs.
c4c7be9f0554f0414bdfc475141e5a19b4137f76: mpatch: move collect() to module level
Augie Fackler <augie@google.com> - Sat, 19 Mar 2016 16:45:52 -0400 - rev 30899
Push 209 by gszorc@mozilla.com at Sun, 27 Mar 2016 04:36:25 +0000
mpatch: move collect() to module level This helps the code read a little more clearly.
6546afde350e26707960a9173a291119ff31f91c: mpatch: un-nest the move() method
Augie Fackler <augie@google.com> - Sat, 19 Mar 2016 16:43:16 -0400 - rev 30898
Push 209 by gszorc@mozilla.com at Sun, 27 Mar 2016 04:36:25 +0000
mpatch: un-nest the move() method This helps the code read a little more clearly.
76d7cab13f042ea56264ab431bef15236147a9bf: mpatch: move pull() method to top level
Augie Fackler <augie@google.com> - Sat, 19 Mar 2016 16:37:30 -0400 - rev 30897
Push 209 by gszorc@mozilla.com at Sun, 27 Mar 2016 04:36:25 +0000
mpatch: move pull() method to top level There was no need for this to be nested.
82cee85d5274f5ce63a74c9cb157ab2592bab332: chgserver: use old ui.system if fout is not stdout or needs to be captured
Jun Wu <quark@fb.com> - Thu, 17 Mar 2016 18:27:48 +0000 - rev 30896
Push 209 by gszorc@mozilla.com at Sun, 27 Mar 2016 04:36:25 +0000
chgserver: use old ui.system if fout is not stdout or needs to be captured Before this patch, chgui will override the system method, forwarding every process execution to the client so sessions and process groups can work as expected. But the chg client will just use stdout, if ui.fout is not stdout or if the output is set to be captured to safe._buffers, the client will not behave correctly. This can happen especially with code prepending "remote:". For example, bundle2 uses ui.pushbuffer, and sshpeer sets fout to ferr. We may have trouble with interactive commands in the fout set to ferr case but if it really bites us, we can always send file descriptors to the client. This patch adds a check to detect the above situations and fallback to the old ui.system if so. It will make chg happy with test-bundle2-exchange.t, test-phases-exchange.t, test-ssh-bundle1.t and test-ssh.t.
a3f3fdac84332e743f9fb930e4bc9ef3bb24e9f8: node: use byte literals to construct nullid and wdirid
Gregory Szorc <gregory.szorc@gmail.com> - Sat, 12 Mar 2016 14:04:57 -0800 - rev 30895
Push 209 by gszorc@mozilla.com at Sun, 27 Mar 2016 04:36:25 +0000
node: use byte literals to construct nullid and wdirid Python 3's hex() insists on operating on bytes. This patch gives it what it wants. '' and b'' in Python 2 are equivalent, so this has no impact on Python 2.
d69172ddfdca8ddfced86a41657302abbb357517: tests: try to import modules with Python 3
Gregory Szorc <gregory.szorc@gmail.com> - Sat, 12 Mar 2016 14:05:23 -0800 - rev 30894
Push 209 by gszorc@mozilla.com at Sun, 27 Mar 2016 04:36:25 +0000
tests: try to import modules with Python 3 All of mercurial.* is now using absolute_import. Most of mercurial.* is able to ast parse with Python 3. The next big hurdle is being able to import modules using Python 3. This patch adds testing of hgext.* and mercurial.* module imports in Python 3. As the new test output shows, most modules can't import under Python 3. However, many of the failures are due to a common problem in a highly imported module (e.g. the bytes vs str issue in node.py).
260ce2eed951abd696715bf9e32a9855cbc26f5a: tests: perform an ast parse with Python 3
Gregory Szorc <gregory.szorc@gmail.com> - Fri, 18 Mar 2016 16:15:12 -0700 - rev 30893
Push 209 by gszorc@mozilla.com at Sun, 27 Mar 2016 04:36:25 +0000
tests: perform an ast parse with Python 3 Previously, test-check-py3-compat.t parsed Python files with Python 2 and looked for known patterns that are incompatible with Python 3. Now that we have a mechanism for invoking Python 3 interpreters from tests, we can expand check-py3-compat.py and its corresponding .t test to perform an additional AST parse using Python 3. As the test output shows, we identify a number of new parse failures on Python 3. There are some redundant warnings for missing parentheses for the print function. Given the recent influx of patches around fixing these, the redundancy shouldn't last for too long.
cdbc253066965347205f7d9b94e334d775495036: run-tests: add --with-python3 to define a Python 3 interpreter
Gregory Szorc <gregory.szorc@gmail.com> - Fri, 18 Mar 2016 16:17:56 -0700 - rev 30892
Push 209 by gszorc@mozilla.com at Sun, 27 Mar 2016 04:36:25 +0000
run-tests: add --with-python3 to define a Python 3 interpreter Currently, very few parts of Mercurial run under Python 3, notably the test harness. We want to write tests that run Python 3. For example, we want to extend test-check-py3-compat.t to parse and load Python files. However, we have a problem: finding appropriate files requires running `hg files` and this requires Python 2 until `hg` works with Python 3. As a temporary workaround, we add --with-python3 to the test harness to allow us to define the path to a Python 3 interpreter. This interpreter is made available to the test environment via $PYTHON3 so tests can run things with Python 3 while the test harness and `hg` invocations continue to run from Python 2. To round out the feature, a "py3exe" hghave check has been added.
3c8f0a60550466c17cc1993ead24328314a232b4: crecord: add docblock to handlekeypressed
Ryan McElroy <rmcelroy@fb.com> - Fri, 18 Mar 2016 11:06:03 -0700 - rev 30891
Push 209 by gszorc@mozilla.com at Sun, 27 Mar 2016 04:36:25 +0000
crecord: add docblock to handlekeypressed This information is pretty useful when reading the code.
8b41ad798fb749dbe3d5af1ef71bc2221a1ca893: crecord: fix docblock indentation
Ryan McElroy <rmcelroy@fb.com> - Fri, 18 Mar 2016 11:06:03 -0700 - rev 30890
Push 209 by gszorc@mozilla.com at Sun, 27 Mar 2016 04:36:25 +0000
crecord: fix docblock indentation
f571ea254f755e9ebcd713cbd1c96d4dd3f8948d: crecord: clean up empty lines at ends of docblocks
Ryan McElroy <rmcelroy@fb.com> - Fri, 18 Mar 2016 11:06:03 -0700 - rev 30889
Push 209 by gszorc@mozilla.com at Sun, 27 Mar 2016 04:36:25 +0000
crecord: clean up empty lines at ends of docblocks
66d085e55ecd84e96be6b210f081882c15df64e3: filemerge: indicate that local/other are p1/p2
timeless <timeless@mozdev.org> - Thu, 17 Mar 2016 00:36:01 +0000 - rev 30888
Push 209 by gszorc@mozilla.com at Sun, 27 Mar 2016 04:36:25 +0000
filemerge: indicate that local/other are p1/p2
7efff6ce9826689c9b3c98f4551f82d1eae7ea6a: sslutil: use preferred formatting for import syntax
Gregory Szorc <gregory.szorc@gmail.com> - Sat, 19 Mar 2016 10:10:09 -0700 - rev 30887
Push 209 by gszorc@mozilla.com at Sun, 27 Mar 2016 04:36:25 +0000
sslutil: use preferred formatting for import syntax
33bd95443e7f257f63a1c7327cc8a024231cc792: largefiles: add some docstrings
Mads Kiilerich <madski@unity3d.com> - Sat, 19 Mar 2016 08:28:24 -0700 - rev 30886
Push 209 by gszorc@mozilla.com at Sun, 27 Mar 2016 04:36:25 +0000
largefiles: add some docstrings
78e4e558fa74aa4489609953328cbcecf1a8a428: largefiles: drop partial support for not having a user cache
Mads Kiilerich <madski@unity3d.com> - Sat, 19 Mar 2016 08:27:54 -0700 - rev 30885
Push 209 by gszorc@mozilla.com at Sun, 27 Mar 2016 04:36:25 +0000
largefiles: drop partial support for not having a user cache 971c55ce03b8 introduced support for not having a "global" user cache. In the rare cases where the environment didn't provide the location of the current home directory, the usercachepath function could return None. That functionality has since bitrotten and several code paths did not correctly check for usercachepath returning None: $ HOME= XDG_CACHE_HOME= hg up --config extensions.largefiles= getting changed largefiles abort: unknown largefiles usercache location Dropping the partial support for it is thus not really a backward compatibility breaking change. Thus: consistently fail early if the usercache location is unknown. It is relevant to be able to control where the largefiles are stored and how they propagate, but that should probably be done differently. The dysfunctional code just gets in the way.
7a4e1749cb071ae08b09fe5db592d53accc6816d: largefiles: refactor usercachepath - extract user cache path function
Mads Kiilerich <madski@unity3d.com> - Sat, 19 Mar 2016 08:23:55 -0700 - rev 30884
Push 209 by gszorc@mozilla.com at Sun, 27 Mar 2016 04:36:25 +0000
largefiles: refactor usercachepath - extract user cache path function It is convenient to have the user cache location explicitly.
6a42564081cbb470577f640650fb76bd93a7d4a1: shelve: adds restoring newly created branch (issue5048) (BC)
liscju <piotr.listkiewicz@gmail.com> - Wed, 10 Feb 2016 02:23:27 +0100 - rev 30883
Push 209 by gszorc@mozilla.com at Sun, 27 Mar 2016 04:36:25 +0000
shelve: adds restoring newly created branch (issue5048) (BC) Before this patch shelve never preserved branch information, so after applying unshelve branch was the same as it was on working copy no matter in which branch shelve took place. This patch makes bare shelving(with no files specified, without interactive,include and exclude option) remembers information if the working directory was on newly created branch ,in other words working directory was on different branch than its first parent. In this situation unshelving restores branch information to the working directory.
43c204ddf333eafa06651268eb1fe036ec60c00b: shelve: make non bare shelve not saving branch information in bundle
liscju <piotr.listkiewicz@gmail.com> - Mon, 07 Mar 2016 22:58:11 +0100 - rev 30882
Push 209 by gszorc@mozilla.com at Sun, 27 Mar 2016 04:36:25 +0000
shelve: make non bare shelve not saving branch information in bundle This patch prepares for restoring newly created branch only on bare shelve later because information about new-branch will be preserved only when shelve was bare and working copy branch was different than branch of its parent. In other case information about new-branch will be gone, so unshelve will not recognise that shelve was made on new-branch and it will not restore branch information from the bundle to the working directory.
(0) -30000 -10000 -3000 -1000 -100 -50 -20 +20 +300 +10000 tip