Summary:
Add the `storerequirements` feature to the repo. This means the store may have
a `requires` file, and clients must check it for any store features that they
may be missing. This allows new requirements to be added that affect the store
when the repo is shared. Currently there are no store features.
This commit adds support for the feature, and only new repos have the
requirement added. A future commit will optimistically upgrade repos to
include the requirement.
Reviewed By: quark-zju
Differential Revision: D9699156
fbshipit-source-id: 95c1ab6973d44c02abc69b78a15311fe6a8696fd
Summary: Mostly empty lines removed and added. A few bugfixes on excessive line splitting.
Reviewed By: quark-zju
Differential Revision: D8199128
fbshipit-source-id: 90c1616061bfd7cfbba0b75f03f89683340374d5
Summary:
Turned on the auto formatter. Ran `arc lint --apply-patches --take BLACK **/*.py`.
Then run `arc lint` again so some other autofixers like spellchecker etc. looked
at the code base. Manually accept the changes whenever they make sense, or use
a workaround (ex. changing "dict()" to "dict constructor") where autofix is false
positive. Disabled linters on files that are hard (i18n/polib.py) to fix, or less
interesting to fix (hgsubversion tests), or cannot be fixed without breaking
OSS build (FBPYTHON4).
Conflicted linters (test-check-module-imports.t, part of test-check-code.t,
test-check-pyflakes.t) are removed or disabled.
Duplicated linters (test-check-pyflakes.t, test-check-pylint.t) are removed.
An issue of the auto-formatter is lines are no longer guarnateed to be <= 80
chars. But that seems less important comparing with the benefit auto-formatter
provides.
As we're here, also remove test-check-py3-compat.t, as it is currently broken
if `PYTHON3=/bin/python3` is set.
Reviewed By: wez, phillco, simpkins, pkaush, singhsrb
Differential Revision: D8173629
fbshipit-source-id: 90e248ae0c5e6eaadbe25520a6ee42d32005621b
We add a new mode for delta recomputation, when selected, each full text will
go through the full "addrevision" mechanism again. This is slower than
"redeltaall" but this gives the opportunity for extensions to trigger special
logic. For example, the lfs extensions can decide to promote some revision to
lfs storage during the upgrade.
By using the standard path to create a repository we fill some hole in the
current initialization process. The one who triggered this changeset was the
lack of extensions initialization.
The `repo.baseui` contains all the configuration but the one specific to the
repository (so it can be used when dealing with local peer and sub-
repository). However, we need the repository config to be taken into account
when doing the upgrade. Otherwise, the upgrade related config that exists in
the repository config won't be taken into account when performing the update.
A buggy and surprising behavior.
We had to work around protection set around `repo.ui.copy` since we are an
uncommon case.
The new naming is more descriptive of a "state" while the older one was more
about "action". I'm looking into command exposing more of data about the state
of the repository so "state" oriented work better there.
The key has not been made public anywhere outside the debug area so it is fine
to update it.
Some requirement does not directly result from config and needs more advanced
logic to be preserved. The current example is 'largefiles'. We add a hook
point in the upgrade code so that extensions can handle these cases.
The 'largefiles' extension will use it in the next changeset.
This is the result of running:
python codemod_nestedwith.py **/*.py
where codemod_nestedwith.py looks like this:
#!/usr/bin/env python
# codemod_nestedwith.py - codemod tool to rewrite nested with
#
# Copyright 2017 Facebook, Inc.
#
# This software may be used and distributed according to the terms of the
# GNU General Public License version 2 or any later version.
from __future__ import absolute_import, print_function
import sys
import redbaron
def readpath(path):
with open(path) as f:
return f.read()
def writepath(path, content):
with open(path, 'w') as f:
f.write(content)
def main(argv):
if not argv:
print('Usage: codemod_nestedwith.py FILES')
for i, path in enumerate(argv):
print('(%d/%d) scanning %s' % (i + 1, len(argv), path))
changed = False
red = redbaron.RedBaron(readpath(path))
processed = set()
for node in red.find_all('with'):
if node in processed or node.type != 'with':
continue
top = node
child = top[0]
while True:
if len(top) > 1 or child.type != 'with':
break
# estimate line length after merging two "with"s
new = '%swith %s:' % (top.indentation, top.contexts.dumps())
new += ', %s' % child.contexts.dumps()
# only do the rewrite if the end result is within 80 chars
if len(new) > 80:
break
processed.add(child)
top.contexts.extend(child.contexts)
top.value = child.value
top.value.decrease_indentation(4)
child = child[0]
changed = True
if changed:
print('updating %s' % path)
writepath(path, red.dumps())
if __name__ == "__main__":
sys.exit(main(sys.argv[1:]))
Differential Revision: https://phab.mercurial-scm.org/D77
Now that all known format variants exists outside of the function, we can gather
them in a lists. This build a single entry point other code can use (current
target: extensions).
The repository upgrade code is updated to simply use entries from this list.
As a side effect this will also allow extensions to register their own format
variants, to do this "properly" we should introduce a "registrar" for this
category of object. However I prefer to keep this series simple, and that will
be adventure for future time.
Our goal here is to get top level definition for all the format variants. Having
them defined outside of the function enabled other users of that logic.
They are two keys components of a format variant:
1) the name and various descriptions of its effect,
2) the code that checks if the repo is using this variant and if the config
enables it.
That second items make us pick a class-based approach, since different variants
requires different code (even if in practice, many can reuse the same logic).
Each variants define its own class that is then used like a singleton. The
class-based approach also clarify the definitions part a bit since each are
simple assignment in an indented block.
The 'fromdefault' and 'fromconfig' are respectively replaced by a class
attribute and a method to be called at the one place where "fromconfig"
matters.
Overall, they are many viable approach for this, but this is the one I picked.
The 'deficiency' type has multiple specificities. We create a dedicated class to
host them. More logic will be added incrementally in future changesets.
Through the code, we use a mix of 'improvement' object and string. Having a
single type would be simpler. For this we need the object to be comparable.
This sounds like higher level logic to process arguments.
Moving it out of 'determineactions' will allow passing only deficiencies to the
function. Then, in a future changeset, we will remove dispatch on "improvement
type" within the function. See next changeset for details.
Since we already have the list of optimisations independent from the
deficiencies, we can use it directly.
(we make a dual assignement in this changeset to simplify the next one)
Our ultimate goal is to make it easier to get a diagnostic of the repository
format. A first important and step for that is to separate part related to
repository format from the optimisation. We start by having two different
functions returning the two categories of possible "improvement".
Given about 2/3 or 'mercurial.repair' is now about repository upgrade, I think
it is fair to move it into its own module.
An expected benefit is the ability to drop the 'upgrade' prefix of many
functions. This will be done in coming changesets.