Summary: The xrange function doesn't exist in python3, use the pycompat version instead.
Reviewed By: ikostia
Differential Revision: D17607522
fbshipit-source-id: c7b992071ad7933372033892ca99e240aa11ccba
Summary:
The inline revlog format merges `.i` and `.d` into one `.i` file. It was intended to reduce the
number of files for filelogs. For the changelog one extra file does not hurt.
This makes it easier to write native code parsing the changelog revlog index.
Reviewed By: xavierd
Differential Revision: D17125922
fbshipit-source-id: f48ffe0d2df71abec007a80e05b684dcbac71883
Summary:
Opening all the revlogs to validate them is showing up as a performance
bottleneck for hgsql transactions. Let's switch them to using mmap to avoid
reading a bunch of data from disk.
Actually making this have an effect on our servers will also require setting the
experimental.mmapindexthreshold config.
Reviewed By: quark-zju
Differential Revision: D15441867
fbshipit-source-id: 4edde0bc3419ef75f82a4234c9dfc6604c6db9f4
Summary:
This introduces `repo.sqlreporeadonlystate()`, which works similarly to `repo.sqlisreporeadonly()`, but also gets the reason why the read only state is the way it is.
The underlying goal is to use this in a repo hook to report the lock state.
I retained the `sqlisreporeadonly` function so that we don't need to synchronize deployment of this code and the underlying hook.
Reviewed By: quark-zju
Differential Revision: D15165946
fbshipit-source-id: 0a62147167fa826b575178dd261990a956b5f317
Summary:
We have an existing method which can capture the desired functionality
without dropping all the data in the `revision_references` table. This
primarily solves these problems:
- Reuse of code.
Reviewed By: farnz
Differential Revision: D15107057
fbshipit-source-id: 5f9970ffd13536808c1b201481b6d2015fbe8295
Summary:
It makes this method 25-30% faster (shaves off 250-300 ms).
Also it counts number of fetched rows correctly - fetchall method was
overriden, but looks like __iter__ method wasn't
Reviewed By: ikostia
Differential Revision: D14915472
fbshipit-source-id: 313695c1a83d05dac2fc801792226b6b64539cb5
Summary:
When the sql_repo_lock.py hook is run, the sql connection won't have been
established yet. Let's open a connection and clean it up afterwards.
Reviewed By: quark-zju
Differential Revision: D14708851
fbshipit-source-id: f20b6dacdcb12cee839163325164d2e75816100c
Summary:
As part of the mononoke write path rollout we want to be
able to dynamically block writes to a repo. This is implemented as
a table in hgsql (repo_lock) that both hg and mononoke can read, but
will only be updated by scmadmin.
Expose a function that can be used by in-process hooks to check if a repo is
locked for mercurial.
Reviewed By: quark-zju
Differential Revision: D14279169
fbshipit-source-id: f8bb4afeeeda67796cf806ab7f3fe42f4089818f
Summary:
These was probably introduced by moving to black.
The changes in the diff were generated by script.
Reviewed By: mitrandir77, singhsrb
Differential Revision: D14439667
fbshipit-source-id: 54f6e0bdcc59c1c6deb4eea46dc6f865bcd48cf8
Summary:
We need to ensure that memcommit is executed with the hgsql lock if
the `hgsql` extension is enabled.
Reviewed By: DurhamG
Differential Revision: D14177416
fbshipit-source-id: dcabf08003b618579461c608f924fe7f5b796c37
Summary:
D13853115 adds `edenscm/` to `sys.path` and code still uses `import mercurial`.
That has nasty problems if both `import mercurial` and
`import edenscm.mercurial` are used, because Python would think `mercurial.foo`
and `edenscm.mercurial.foo` are different modules so code like
`try: ... except mercurial.error.Foo: ...`, or `isinstance(x, mercurial.foo.Bar)`
would fail to handle the `edenscm.mercurial` version. There are also some
module-level states (ex. `extensions._extensions`) that would cause trouble if
they have multiple versions in a single process.
Change imports to use the `edenscm` so ideally the `mercurial` is no longer
imported at all. Add checks in extensions.py to catch unexpected extensions
importing modules from the old (wrong) locations when running tests.
Reviewed By: phillco
Differential Revision: D13868981
fbshipit-source-id: f4e2513766957fd81d85407994f7521a08e4de48
Summary:
Move top-level Python packages `mercurial`, `hgext` and `hgdemandimport` to
a new top-level package `edenscm`. This allows the Python packages provided by
the upstream Mercurial to be installed side-by-side.
To maintain compatibility, `edenscm/` gets added to `sys.path` in
`mercurial/__init__.py`.
Reviewed By: phillco, ikostia
Differential Revision: D13853115
fbshipit-source-id: b296b0673dc54c61ef6a591ebc687057ff53b22e
