Gregory Szorc <gregory.szorc@gmail.com> [Mon, 09 Apr 2018 12:27:52 -0700] rev 37627
setup: add packages for concurrent.futures
We conceivably don't need to distribute this package on Python 3
since we will use the version in the standard library. However,
we want installs to be usable of multiple versions of Python. So
it is best to always have it.
Differential Revision: https://phab.mercurial-scm.org/D3265
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 09 Apr 2018 12:23:48 -0700] rev 37626
futures: switch to absolute and relative imports
This makes the package conform with our importing policy,
silencing a number of warnings. It also makes the package usable
when it isn't named "concurrent.futures."
Differential Revision: https://phab.mercurial-scm.org/D3264
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 09 Apr 2018 12:22:31 -0700] rev 37625
tests: silence pyflakes for thirdparty/concurrent
It is complaining about unused imports.
Differential Revision: https://phab.mercurial-scm.org/D3263
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 09 Apr 2018 12:19:37 -0700] rev 37624
futures: get rid of extend_path
This is used so mutliple directories can provide a package. We don't
need it when vendoring.
Differential Revision: https://phab.mercurial-scm.org/D3262
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 11 Apr 2018 14:48:24 -0700] rev 37623
thirdparty: vendor futures 3.2.0
Python 3 has a concurrent.futures package in the standard library
for representing futures. The "futures" package on PyPI is a backport
of this package to work with Python 2.
The wire protocol code today has its own future concept for handling
of "batch" requests. The frame-based protocol will also want to
use futures.
I've heavily used the "futures" package on Python 2 in other projects
and it is pretty nice. It even has a built-in thread and process pool
for running functions in parallel. I've used this heavily for concurrent
I/O and other GIL-less activities.
The existing futures API in the wire protocol code is not as nice as
concurrent.futures. Since concurrent.futures is in the Python standard
library and will presumably be the long-term future for futures in our
code base, let's vendor the backport so we can use proper futures today.
# no-check-commit because of style violations
Differential Revision: https://phab.mercurial-scm.org/D3261
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 12 Apr 2018 15:05:49 +0530] rev 37622
py3: make sure decode() first argument is str
Uses pycompat.sysstr() to make sure we uses bytes on Python 2 and unicodes on
Python 3.
Differential Revision: https://phab.mercurial-scm.org/D3279
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 12 Apr 2018 23:14:38 -0700] rev 37621
patch: make extract() a context manager (API)
Previously, this function was creating a temporary file and relying
on callers to unlink it. Yuck.
We convert the function to a context manager and tie the lifetime of
the temporary file to that of the context manager. This changed
indentation not only from the context manager, but also from the
elination of try blocks. It was just easier to split the heart of
extract() into its own function.
The single consumer of this function has been refactored to use it as
a context manager. Code for cleaning up the file in tryimportone()
has also been removed.
.. api::
``patch.extract()`` is now a context manager. Callers no longer have
to worry about deleting the temporary file it creates, as the file is
tied to the lifetime of the context manager.
Differential Revision: https://phab.mercurial-scm.org/D3306
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 12 Apr 2018 23:06:27 -0700] rev 37620
cmdutil: pass in parsed patch to tryimportone() (API)
Previously, we parsed the patch in tryimportone(). This assumes the
input is in a patch format that needs to be parsed. We want to support
feeding in data from other formats. So let's let the caller handle the
parsing.
One wonky thing about patch parsing is that patch.extract() creates
a temp file to hold the diffs and it is up to tryimportone() to
unlink that temp file. I'll improve this in a subsequent commit.
Differential Revision: https://phab.mercurial-scm.org/D3305
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 12 Apr 2018 20:42:42 -0700] rev 37619
stringutil: support more types with pprint()
bytearray wasn't working. Integers and floats were not being
formatted.
I /think/ %f is portable across both Python 2 and 3, as it should
default to 6 decimal points on each.
Differential Revision: https://phab.mercurial-scm.org/D3302
Augie Fackler <augie@google.com> [Thu, 12 Apr 2018 14:27:13 -0400] rev 37618
fix: port most of the way to python 3
Only most of the way because we now have to decide: if we want to keep
the current .format() interface for the config in hgrc, we have to use
unicodes to do formatting in Python 3, rather than bytes. I'm
basically fine with that, so a follow-up patch will do so.
Differential Revision: https://phab.mercurial-scm.org/D3300
Matt Harbison <matt_harbison@yahoo.com> [Thu, 12 Apr 2018 17:24:55 -0700] rev 37617
lfs: teach the blob server to handle --prefix
Matt Harbison <matt_harbison@yahoo.com> [Thu, 05 Apr 2018 15:42:40 -0400] rev 37616
hgweb: fallback to checking wsgireq.env for REPO_NAME for 3rd party hosting
Starting with
d7fd203e36cc, SCM Manager began to 404 any repository access.
What's happening is that it is generating a python script that creates an hgweb
application (not hgwebdir), and launches hgweb via wsgicgi. It must be setting
REPO_NAME in the process environment before launching this script, which gets
picked up and put into wsgireq.env when wsgicgi launches the hgweb application.
>From there, other variables (notably 'apppath' and 'dispatchpath') are
constructed differently.
d7fd203e36cc^ (working):
apppath: /hg/eng/devsetup
dispatchpath:
pathinfo: /eng/devsetup
reponame: eng/devsetup
d7fd203e36cc:
apppath: /hg
dispatchpath: eng/devsetup
pathinfo: /eng/devsetup
reponame: None
REPO_NAME: eng/devsetup
Rather than having an existing installation break when Mercurial is upgraded,
just resume checking the environment. I have no idea how many other hosting
solutions would break without restoring this.
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 11 Apr 2018 12:51:09 -0700] rev 37615
peer: scatter module to the wind (API)
peer.py hardly contained any code. The code it did contain was
generic to the version 1 peer interface or specific to the
local repository peer.
So code has been moved to wireprotov1peer and localrepo, as
appropriate.
Differential Revision: https://phab.mercurial-scm.org/D3260
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 11 Apr 2018 12:49:08 -0700] rev 37614
wireproto: move version 1 peer functionality to standalone module (API)
wireproto.py contains code for both the client and the server. There
*should* be a somewhat strong separation between the two.
This commit extracts the client-side code from wireproto.py into a new
module - wireprotov1peer.
Differential Revision: https://phab.mercurial-scm.org/D3259
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 11 Apr 2018 10:51:38 -0700] rev 37613
wireproto: move gboptsmap to wireprototypes and rename (API)
This is also shared between client and server and will need to
exist in a shared module when that code is split into different
modules.
Differential Revision: https://phab.mercurial-scm.org/D3258
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 11 Apr 2018 10:50:58 -0700] rev 37612
wireproto: move value encoding functions to wireprototypes (API)
These functions should live in the same place. I plan to separate
client from server code in upcoming commits. wireprototypes is
where we are putting shared code like this.
Differential Revision: https://phab.mercurial-scm.org/D3257
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 10 Apr 2018 19:09:35 -0700] rev 37611
httppeer: basic implementation of capabilities interface
This is a bit crude. The capabilities mechanism for version 2 of
the wire protocol is a bit different from version 1. And code
in core is relying on strings passed to capable() matching strings
advertised by the "capabilities" wire protocol command. I may
refactor the internal checking mechanism to be a bit more
abstract or based on interfaces. Time will tell...
Differential Revision: https://phab.mercurial-scm.org/D3256
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 10 Apr 2018 18:47:09 -0700] rev 37610
repository: split capabilities methods into separate interface
So we can implement them without having to implement support for
every command.
Differential Revision: https://phab.mercurial-scm.org/D3255
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 11 Apr 2018 11:03:45 -0700] rev 37609
httppeer: implement ipeerconnection
This is low hanging fruit. We might as well start somewhere.
Differential Revision: https://phab.mercurial-scm.org/D3254
Augie Fackler <augie@google.com> [Thu, 12 Apr 2018 13:25:54 -0400] rev 37608
py3: whitelist another six passing tests
Differential Revision: https://phab.mercurial-scm.org/D3286
Augie Fackler <augie@google.com> [Wed, 11 Apr 2018 17:43:00 -0400] rev 37607
py3: whitelist another nine passing tests
Differential Revision: https://phab.mercurial-scm.org/D3253
Augie Fackler <augie@google.com> [Wed, 11 Apr 2018 14:01:37 -0400] rev 37606
hgweb: use our forked wsgiheaders module instead of stdlib one
Now we use bytes for headers, rather than native strings.
Differential Revision: https://phab.mercurial-scm.org/D2854
Augie Fackler <augie@google.com> [Thu, 12 Apr 2018 10:00:09 -0700] rev 37605
wsgiheaders: import a bytes-ified fork of wsgiref.headers from cpython@46f5072
This will let us restore Python 3 compatibility for tests that do http things.
Differential Revision: https://phab.mercurial-scm.org/D3245
Yuya Nishihara <yuya@tcha.org> [Thu, 12 Apr 2018 23:13:55 +0900] rev 37604
export: enable formatter support (API)
This change is basically the same as "hg cat". A formatter object is created
by caller.
.. api::
``cmdutil.export()`` takes a formatter as an argument.
Yuya Nishihara <yuya@tcha.org> [Thu, 12 Apr 2018 22:59:49 +0900] rev 37603
export: extract function to write patch to file object (API)
This is common use case of cmdutil.export(), and we wouldn't want to handle
formatter thingy everywhere.
.. api::
The ``fp`` argument is removed from ``cmdutil.export()``. Use
``cmdutil.exportfile()`` instead.
Yuya Nishihara <yuya@tcha.org> [Thu, 12 Apr 2018 22:39:43 +0900] rev 37602
export: port _exportsingle() to formatter
Pass 'fm' instead of 'write', and use fm.plain(), fm.write(), etc. instead.
The callers will be updated later.
Yuya Nishihara <yuya@tcha.org> [Thu, 12 Apr 2018 22:08:55 +0900] rev 37601
export: serialize revisions to be exported per destination file
Prepares for porting to the formatter API, where we can't simply append
to existing files because JSON can't be streamed for example.
The modemap hack is removed since cmdutil.export() was the only user.
I also made the destination filename printed only once.
Yuya Nishihara <yuya@tcha.org> [Thu, 12 Apr 2018 21:56:02 +0900] rev 37600
export: split cmdutil.export() to single-file and maybe-multiple-files cases
Porting "hg export" to formatter is a bit hard because cmdutil.export() may
append to files if the fntemplate is specified. This patch splits the hard
part from the trivial case.
Yuya Nishihara <yuya@tcha.org> [Thu, 12 Apr 2018 21:47:17 +0900] rev 37599
export: remove unused argument 'rev' from _exportsingle()
Yuya Nishihara <yuya@tcha.org> [Thu, 12 Apr 2018 21:33:47 +0900] rev 37598
export: do not start pager if output will be written to file
A copy of
3b569745af6c.