##// END OF EJS Templates
narrow: only send the narrowspecs back if ACL in play...
narrow: only send the narrowspecs back if ACL in play I am unable to think why we need to send narrowspecs back from the server. The current state adds a 'narrow:spec' part to each changegroup which is generated when narrow extension is enabled. So we are sending narrowspecs on pull also. There is a problem with sending the narrowspecs the way we are doing it right now. We add include and exclude as parameter of the 'narrow:spec' bundle2 part. The the len of include or exclude string increase 255 which is obvious while working on large repos, bundle2 generation code breaks. For more on that refer issue5952 on bugzilla. I was thinking why we need to send the narrowspecs back, and deleted the 'narrow:spec' bundle2 part generation code and found that only narrow-acl test has some failure. With this patch, we will only send the 'narrow:spec' bundle2 part if ACL is enabled because the original narrowspecs in those cases can be a subset of narrowspecs user requested. There are phase related output change in couple of tests. The output change shows that we are now dealing in public phases completely. So maybe sending the narrow:spec bundle2 part was preventing phases being exchanged or phase bundle2 data being applied. Differential Revision: https://phab.mercurial-scm.org/D4931

File last commit:

r40157:73fef626 default
r40373:cb516a85 default
Show More
__init__.py
65 lines | 2.4 KiB | text/x-python | PythonLexer
# Copyright (c) 2017-present, Gregory Szorc
# All rights reserved.
#
# This software may be modified and distributed under the terms
# of the BSD license. See the LICENSE file for details.
"""Python interface to the Zstandard (zstd) compression library."""
from __future__ import absolute_import, unicode_literals
# This module serves 2 roles:
#
# 1) Export the C or CFFI "backend" through a central module.
# 2) Implement additional functionality built on top of C or CFFI backend.
import os
import platform
# Some Python implementations don't support C extensions. That's why we have
# a CFFI implementation in the first place. The code here import one of our
# "backends" then re-exports the symbols from this module. For convenience,
# we support falling back to the CFFI backend if the C extension can't be
# imported. But for performance reasons, we only do this on unknown Python
# implementation. Notably, for CPython we require the C extension by default.
# Because someone will inevitably want special behavior, the behavior is
# configurable via an environment variable. A potentially better way to handle
# this is to import a special ``__importpolicy__`` module or something
# defining a variable and `setup.py` could write the file with whatever
# policy was specified at build time. Until someone needs it, we go with
# the hacky but simple environment variable approach.
_module_policy = os.environ.get('PYTHON_ZSTANDARD_IMPORT_POLICY', 'default')
if _module_policy == 'default':
if platform.python_implementation() in ('CPython',):
from zstd import *
backend = 'cext'
elif platform.python_implementation() in ('PyPy',):
from zstd_cffi import *
backend = 'cffi'
else:
try:
from zstd import *
backend = 'cext'
except ImportError:
from zstd_cffi import *
backend = 'cffi'
elif _module_policy == 'cffi_fallback':
try:
from zstd import *
backend = 'cext'
except ImportError:
from zstd_cffi import *
backend = 'cffi'
elif _module_policy == 'cext':
from zstd import *
backend = 'cext'
elif _module_policy == 'cffi':
from zstd_cffi import *
backend = 'cffi'
else:
raise ImportError('unknown module import policy: %s; use default, cffi_fallback, '
'cext, or cffi' % _module_policy)
# Keep this in sync with python-zstandard.h.
__version__ = '0.10.1'