Pulkit Goyal <pulkit@yandex-team.ru> [Sat, 15 Sep 2018 00:37:20 +0300] rev 39637
py3: call hgweb.hgweb() with bytes values
# skip-blame because just b'' prefixes
I believe this should fix some tests.
Differential Revision: https://phab.mercurial-scm.org/D4594
Pulkit Goyal <pulkit@yandex-team.ru> [Sat, 15 Sep 2018 00:24:05 +0300] rev 39636
py3: use '%d' for integers instead of '%s'
Differential Revision: https://phab.mercurial-scm.org/D4593
Pulkit Goyal <pulkit@yandex-team.ru> [Sat, 15 Sep 2018 00:17:56 +0300] rev 39635
py3: use "%f" for floats instead of "%s"
Differential Revision: https://phab.mercurial-scm.org/D4592
Pulkit Goyal <pulkit@yandex-team.ru> [Sat, 15 Sep 2018 00:01:52 +0300] rev 39634
py3: suppress the return value from .write() call
Differential Revision: https://phab.mercurial-scm.org/D4591
Pulkit Goyal <pulkit@yandex-team.ru> [Sat, 15 Sep 2018 00:01:20 +0300] rev 39633
py3: add b'' prefixes in tests/test-diff-color.t
# skip-blame because just b'' prefixes
Differential Revision: https://phab.mercurial-scm.org/D4590
Pulkit Goyal <pulkit@yandex-team.ru> [Fri, 14 Sep 2018 23:59:41 +0300] rev 39632
py3: slice through bytes to prevent getting ascii value
I still don't know why python-dev thought it was a nice idea to do this.
Differential Revision: https://phab.mercurial-scm.org/D4589
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Thu, 13 Sep 2018 16:22:53 -0400] rev 39631
censor: use a reasonable amount of memory
Before this change, trying to censor some random revision uses an ever
increasing amount of memory (I stopped at 20GB, but it was by no means
finished), presumably because these contexts have a lot of
information that is kept alive.
After this change, the memory usage plateaus quickly.
Differential Revision: https://phab.mercurial-scm.org/D4582
Yuya Nishihara <yuya@tcha.org> [Fri, 14 Sep 2018 22:25:44 +0900] rev 39630
help: add internals.wireprotocolrpc to the table
Yuya Nishihara <yuya@tcha.org> [Fri, 14 Sep 2018 22:23:02 +0900] rev 39629
setup: exclude vendored futures package on Python 3
The vendored future can't live on Python 3.
Augie Fackler <augie@google.com> [Thu, 13 Sep 2018 11:08:08 -0400] rev 39628
py3: whitelist another passing test
Differential Revision: https://phab.mercurial-scm.org/D4562
Matt Harbison <matt_harbison@yahoo.com> [Thu, 13 Sep 2018 00:42:25 -0400] rev 39627
py3: prevent the win32 ctype _fields_ from being transformed to bytes
Otherwise, any hg invocation dies with
TypeError: '_fields_' must be a sequence of (name, C type) pairs
# skip-blame just a r prefix
Matt Harbison <matt_harbison@yahoo.com> [Thu, 13 Sep 2018 17:32:20 -0400] rev 39626
cext: fix warnings when building for py3 on Windows
MSVC++ 14 now has standard int types that don't need to be redefined (I didn't
go back to see when they came along since the build system wants either 2008 or
2015), but doesn't have ssize_t. The FILE pointer in posixfile is only used on
python2.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 13 Sep 2018 12:43:50 -0400] rev 39625
cext: stop preprocessing a partial function call
MSVC++ 14 yelled:
mercurial/cext/revlog.c(1913): fatal error C1057: unexpected end of file in
macro expansion
At this point, the C extensions build (with warnings), and it dies in win32.py
because the `_fields_` strings in the ctypes classes are being converted to
bytes by the source translator.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 13 Sep 2018 12:37:32 -0400] rev 39624
py3: add b'' to some setup.py strings for Windows
These were things found trying to do `make PYTHON="py -3" local`. The following
is dumped out, before dying while compiling the C extensions:
C:\Program Files\Python37\lib\site-packages\setuptools\dist.py:406: UserWarning:
The version specified (b'4.7.1') is an invalid version, this may not work as
expected with newer versions of setuptools, pip, and PyPI. Please see PEP 440
for more details.
"details." % self.metadata.version
running build_py
byte-compiling .\mercurial\thirdparty\concurrent\futures\_base.py to _base.cpython-37.pyc
File "mercurial\thirdparty\concurrent\futures\_base.py", line 416
raise exception_type, self._exception, self._traceback
^
SyntaxError: invalid syntax
# skip-blame since these are just converting to bytes literals
Augie Fackler <augie@google.com> [Thu, 13 Sep 2018 18:09:22 -0400] rev 39623
dagop: fix typo spotted while doing unrelated investigation
Differential Revision: https://phab.mercurial-scm.org/D4584
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 12 Sep 2018 19:00:46 -0700] rev 39622
hg: don't reuse repo instance after unshare()
Unsharing a repository is a pretty invasive procedure and fundamentally
changes the behavior of the repository.
Currently, hg.unshare() calls into localrepository.__init__ to
re-initialize the repository instance. This is a bit hacky. And
future commits that refactor how localrepository instances are
constructed will make this difficult to support.
This commit changes unshare() so it constructs a new repo instance
once the unshare I/O has completed. It then poisons the old repo
instance so any further use will result in error.
Surprisingly, nothing in core appears to access a repo instance
after it has been unshared!
.. api::
``hg.unshare()`` now poisons the repo instance so it can't be used.
It also returns a new repo instance suitable for interacting with
the unshared repository.
Differential Revision: https://phab.mercurial-scm.org/D4557
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 11 Sep 2018 20:06:39 -0700] rev 39621
unionrepo: dynamically create repository type from base repository
This is basically the same thing we just did for bundlerepo except
for union repositories.
.. api::
``unionrepo.unionrepository()`` is no longer usable on its own.
To instantiate an instance, call ``unionrepo.instance()`` or
``unionrepo.makeunionrepository()``.
Differential Revision: https://phab.mercurial-scm.org/D4556
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 11 Sep 2018 19:50:07 -0700] rev 39620
bundlerepo: dynamically create repository type from base repository
Previously, bundlerepository inherited from localrepo.localrepository.
You simply instantiated a bundlerepository and its __init__ called
localrepo.localrepository.__init__. Things were simple.
Unfortunately, this strategy is limiting because it assumes that
the base repository is a localrepository instance. And it assumes
various properties of localrepository, such as the arguments its
__init__ takes. And it prevents us from changing behavior of
localrepository.__init__ without also having to change derived classes.
Previous and ongoing work to abstract storage revealed these
limitations.
This commit changes the initialization strategy of bundle repositories
to dynamically create a type to represent the repository. Instead of
a static type, we instantiate a new local repo instance via
localrepo.instance(). We then combine its __class__ with
bundlerepository to produce a new type. This ensures that no matter
how localrepo.instance() decides to create a repository object, we
can derive a bundle repo object from it. i.e. localrepo.instance()
could return a type that isn't a localrepository and it would "just
work."
Well, it would "just work" if bundlerepository's custom implementations
only accessed attributes in the documented repository interface. I'm
pretty sure it violates the interface contract in a handful of
places. But we can worry about that another day. This change gets us
closer to doing more clever things around instantiating repository
instances without having to worry about teaching bundlerepository about
them.
.. api::
``bundlerepo.bundlerepository`` is no longer usable on its own.
The class is combined with the class of the base repository it is
associated with at run-time.
New bundlerepository instances can be obtained by calling
``bundlerepo.instance()`` or ``bundlerepo.makebundlerepository()``.
Differential Revision: https://phab.mercurial-scm.org/D4555
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 11 Sep 2018 19:16:32 -0700] rev 39619
bundlerepo: factor out code for instantiating a bundle repository
This code will soon become a bit more complicated. So extract to its
own function.
And change both instantiators of bundlerepository to use it.
Differential Revision: https://phab.mercurial-scm.org/D4554
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 11 Sep 2018 18:45:05 -0700] rev 39618
bundlerepo: pass create=True
I don't want to know how this came to be. Maybe a holdover from the
days before Python had a bool type?
Differential Revision: https://phab.mercurial-scm.org/D4553
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 11 Sep 2018 18:41:14 -0700] rev 39617
shelve: use bundlerepo.instance() to construct a repo object
The instance() functions are preferred over cls.__init__ for
creating repo instances. It doesn't really matter now. But future
commits will refactor the bundlerepository class in ways that will
cause the old way to break.
Differential Revision: https://phab.mercurial-scm.org/D4552
Yuya Nishihara <yuya@tcha.org> [Sun, 29 Jul 2018 22:04:01 +0900] rev 39616
templatekw: add experimental {status} keyword
This is another example of fctx-based keywords. I think this is somewhat
useful in log templates.
Yuya Nishihara <yuya@tcha.org> [Sun, 29 Jul 2018 21:52:01 +0900] rev 39615
templatekw: add option to include ignored/clean/unknown files in cache
They will be necessary to provide {status} of files.
Yuya Nishihara <yuya@tcha.org> [Sun, 29 Jul 2018 22:07:42 +0900] rev 39614
templatekw: keep status tuple in cache dict and rename cache key accordingly
There's no point to drop tail elements, which are mostly empty lists.
Yuya Nishihara <yuya@tcha.org> [Sun, 29 Jul 2018 21:39:12 +0900] rev 39613
templatekw: extract function that computes and caches file status
Yuya Nishihara <yuya@tcha.org> [Thu, 13 Sep 2018 22:32:51 +0900] rev 39612
py3: use sysstr() to convert ProgrammingError bytes with no unicode error risk
msg.decode('utf8') may fail if msg isn't an ASCII string, and that's possible
as we sometimes embed a filename in the error message for example.
Boris Feld <boris.feld@octobus.net> [Mon, 10 Sep 2018 08:31:41 +0200] rev 39611
revlog: reuse cached delta for identical base revision (issue5975)
Since 8f83a953dddf, we skip over empty deltas when choosing a delta base. Such
delta happens when two distinct revisions have the same content.
The remote might be sending a delta against such revision within the bundle.
In that case, the delta base is no longer considered, but the cached one could
still, be used with the equivalent revision.
Not reusing the delta from the bundle can have a significant performance
impact, so we now make sure with doing so when possible.
Boris Feld <boris.feld@octobus.net> [Mon, 10 Sep 2018 10:11:21 +0200] rev 39610
snapshot: fix line order when skipping over empty deltas
The code movement in 37957e07138c introduced an error.
Since 8f83a953dddf, we discarded some revisions because they are identical to
their delta base (and use that delta base instead). That logic is good,
however, in 37957e07138c we mixed up the order of two line, adding the "new"
revision to the set of already tested one, instead of the discarded one. So in
practice, we were never investigating any revisions in a chain starting with
an empty delta. Creating significantly worst delta chain (eg: Mercurial's
manifest move goes from about 60MB up to about 80MB).
Matt Harbison <matt_harbison@yahoo.com> [Wed, 12 Sep 2018 23:10:59 -0400] rev 39609
tests: stabilize change for handling not quoting non-empty-directory
The change originated in cb1329738d64. I suspect the problem is with the
combination of (re) and the '\' to '/' retry on Windows. I've no idea if py3 on
Windows needs the quoting, since it can't even run `hg` with no arguments.
(It's dying somewhere on the ctype declarations when win32.py is imported.)
Augie Fackler <augie@google.com> [Tue, 21 Aug 2018 15:25:46 -0400] rev 39608
hg: wrap the highest layer in the `hg` script possible in trace event
This should help us have a better idea of what "interpreter startup
costs" look like. This does omit the HGUNICODEPEDANTRY block and the
LIBDIR dancing to set up sys.path, but the former is usually off and
the latter is unavoidable and should be very fast. If we get worried
about those cases we can consider open-coding the tracing logic here.
Differential Revision: https://phab.mercurial-scm.org/D4346
Martin von Zweigbergk <martinvonz@google.com> [Wed, 12 Sep 2018 12:01:32 -0700] rev 39607
localrepo: use urllocalpath() for path to create repo too
It looks like this was lost in 7ce9dea3a14a (localrepo: move repo
creation logic out of localrepository.__init__ (API), 2018-09-11). I
don't know when it makes a difference (maybe on Windows, since
urllocalpath() mentions something about drive letters).
Differential Revision: https://phab.mercurial-scm.org/D4550
Martin von Zweigbergk <martinvonz@google.com> [Wed, 12 Sep 2018 08:41:00 -0700] rev 39606
localrepo: move check for existing repo into createrepository()
For symmetry with the check for existence of a repo in
localrepository.__init__, we should check for the non-existence in
createrepository(). We could alternatively move both checks into
instance().
Differential Revision: https://phab.mercurial-scm.org/D4549
Matt Harbison <matt_harbison@yahoo.com> [Wed, 12 Sep 2018 21:32:08 -0400] rev 39605
py3: add b'' to some run-tests.py strings for Windows
Things go seriously off the rails after this, so there may be more that are
missing.
# skip-blame since these are just converting to bytes literals
Augie Fackler <raf@durin42.com> [Wed, 12 Sep 2018 19:14:28 -0400] rev 39604
wireprotov1peer: forward __name__ of wrapped method in batchable decorator
Not required, but clarifies debugging when the going gets really tough.
Differential Revision: https://phab.mercurial-scm.org/D4551
Yuya Nishihara <yuya@tcha.org> [Sun, 29 Jul 2018 21:28:51 +0900] rev 39603
templatekw: add {size} keyword as an example of fctx-based keyword
I'll add {status}, and I think some lfs keywords can be migrated to this.
I'm not certain how many fctx-based keywords will be introduced into the
global space, but if there are a couple more, we'll probably need to sort
them out to the "File Keywords" section in the templater help. Until then,
fctx keywords are hidden as experimental.
Yuya Nishihara <yuya@tcha.org> [Sun, 29 Jul 2018 21:25:37 +0900] rev 39602
formatter: populate fctx from ctx and path value
Tests will be added by the next patch.
Yuya Nishihara <yuya@tcha.org> [Thu, 07 Jun 2018 21:36:13 +0900] rev 39601
formatter: factor out function that detects node change and document it
This prepares for demand loading of ctx/fctx objects. With this change,
'revcache' is also recreated if 'node' value changes, which will be needed
to support loading of ctx from (repo, node) pair.
Yuya Nishihara <yuya@tcha.org> [Sat, 01 Sep 2018 15:06:05 +0900] rev 39600
formatter: inline _gettermap and _knownkeys
Yuya Nishihara <yuya@tcha.org> [Sat, 01 Sep 2018 13:21:45 +0900] rev 39599
formatter: fill missing resources by formatter, not by resource mapper
While working on demand loading of ctx/fctx objects, I found it's weird
to support lookup in both directions. For instance, fctx can be loaded
from (ctx, path) pair, but ctx may also be derived from fctx.changectx()
in the original mapping. If the original mapping has had fctx but no ctx,
and if the new mapping provides {path}, we can't be sure if fctx should be
updated by fctx'.changectx()[path] or not.
This patch simply drops the support for the resolution in fctx -> ctx -> repo
direction.
Yuya Nishihara <yuya@tcha.org> [Thu, 07 Jun 2018 23:27:54 +0900] rev 39598
templater: remove unused context argument from most resourcemapper functions
While working on demand loading of ctx/fctx objects, I noticed that it's quite
easy to create infinite recursion by carelessly using the template context in
the resource mapper. Let's make that not happen.
Yuya Nishihara <yuya@tcha.org> [Mon, 10 Sep 2018 20:57:18 +0900] rev 39597
ancestor: remove extra generator from lazyancestors.__iter__()
Martin von Zweigbergk <martinvonz@google.com> [Wed, 12 Sep 2018 11:24:51 -0700] rev 39596
localrepo: fix a mixmatched arg name in createrepository() docstring
Differential Revision: https://phab.mercurial-scm.org/D4548
Augie Fackler <augie@google.com> [Wed, 12 Sep 2018 11:37:34 -0400] rev 39595
error: ensure ProgrammingError message is always a str
Since this error is internal-only and a runtime error, let's give it a
treatment that makes it behave identically when repr()d on both Python
2 and Python 3.
Differential Revision: https://phab.mercurial-scm.org/D4545
Augie Fackler <augie@google.com> [Wed, 12 Sep 2018 11:39:48 -0400] rev 39594
py3: whitelist a test caught by the ratchet
Differential Revision: https://phab.mercurial-scm.org/D4547
Augie Fackler <augie@google.com> [Wed, 12 Sep 2018 11:38:46 -0400] rev 39593
tests: handle Python 3 not quoting non-empty-directory error
I assume this happens on Windows too, so I did the same regex on both
versions of the output. The whole message printed by these aborts
comes from Python, so if we want to exert control over the quoting
here it'll be a bit of a pain.
Differential Revision: https://phab.mercurial-scm.org/D4546
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 12 Sep 2018 17:45:43 +0300] rev 39592
context: don't count deleted files as candidates for path conflicts in IMM
This patch makes sure we don't consider the deleted files in our IMM wctx
as potential conflicts while calculating paths conflicts. This fixes the bug
demonstrated in previous patch.
Differential Revision: https://phab.mercurial-scm.org/D4543
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 12 Sep 2018 17:22:46 +0300] rev 39591
rebase: add tests showing patch conflict detection needs to be smarter in IMM
This patch adds test which shows that you can't rebase a cset which removes a
dir and adds a file of the same as that of dir as there are False positives
path conflicts reported.
I fixed the case when there is a file and we adds a dir of same name while
removing the file, but missed testing the current case. Next patch will fix
this.
Differential Revision: https://phab.mercurial-scm.org/D4544
Anton Shestakov <av6@dwimlabs.net> [Mon, 10 Sep 2018 16:47:02 +0800] rev 39590
zsh_completion: add new and remove deprecated flags
Differential Revision: https://phab.mercurial-scm.org/D4519