Summary:
The simplecache test attempts to connect to a memcache instance on localhost.
This means the test fails if a memcache instance is not available.
Remove the use of memcache in the test. We still test local files, and assume
that memcache itself works.
Also corrupt the correct key when testing corruption handling, and document the
config options.
Reviewed By: quark-zju
Differential Revision: D13818471
fbshipit-source-id: 6ca7f575aa813f95773144be5337796f029ffd90
Summary:
Move all Rust bindings to a single python extension, `bindings`. This should
improve compilation time and make things simpler.
Reviewed By: quark-zju
Differential Revision: D13923866
fbshipit-source-id: 560592b5a6c0c4f1b836c755ef123666a1059164
Summary: This just reuses the AsyncHistoryStore methods.
Reviewed By: DurhamG
Differential Revision: D13891142
fbshipit-source-id: 9553e9824eebc5eacf6a82f9d0f212a62ec8955f
Summary:
Similarly to AsyncDataStore, this is just a blocking wrapper around a
HistoryStore.
Reviewed By: DurhamG
Differential Revision: D13891140
fbshipit-source-id: 76acadfc1849770b47e2400ce8c70f7e32bba4df
Summary:
We will probably not be supporting secret phase in the future anyway
so lets get rid of it.
Reviewed By: quark-zju
Differential Revision: D13928907
fbshipit-source-id: 7edcd84d2ee3c37124dcf9d3ba92c0610d074157
Summary: This will be used to wrap an HistoryStore into a AsyncHistoryStore.
Reviewed By: DurhamG
Differential Revision: D13891139
fbshipit-source-id: 41a0ec740f05268259a654e769ff0909617102ff
Summary:
Add an option that let's us specify the date of each commit in a pushrebase.
It should be specified via a config option, which accepts a name of a file in
which json dictionary should be stored. Key of this dictionary is a commit hash, value
is a date.
Reviewed By: ikostia
Differential Revision: D13803174
fbshipit-source-id: 6271c18c61399b89c92dce7a4fe63c8fae8dae7c
Summary: Add metadata to each delta entry written to the datapack. Since the HTTP API never serves LFS files, and the only flag currently used simple indicates whether a file should use LFS, the flag field is intentionally set to `None`, leaving only the size in the metadata (which, since we're storing full file content, is the same as the content length).
Differential Revision: D13894292
fbshipit-source-id: 36db25adb0c46cd1c7fde841a69d3e6d48d08d06
Summary: Previously, `hg debuggetfile` would allow fetching a single file from the API server. This diff updates the command to `hg debuggetfiles`, which accepts a list of filenode/path pairs on stdin, and fetches all the files concurrently, writing the contents to a single datapack.
Reviewed By: DurhamG
Differential Revision: D13893894
fbshipit-source-id: 36fc54f1870273ab4b447de5d615b3fb6aaa3378
Summary: Expose `MononokeClient`'s multi-get functionality through the Python bindings using a builder-style API.
Differential Revision: D13893748
fbshipit-source-id: 312e7449eb8300432b1f1de28e0c6fc3e47d1d53
Summary: Give MononokeClient the ability to fetch multiple files concurrently. Right now this functionality is not exposed via the Python bindings, so as far as the Mercurial Python code is concerned, nothing has changed. The multi-get functionality will be used later in the stack.
Differential Revision: D13893575
fbshipit-source-id: c9e514fbeb41bbb37f52f6df3920eb01a66df293
Summary: As `MononokeClient` grows, we're going to add more inherent methods on the struct. To avoid cluttering the `client` module, split out all the builder-related things into a separate module.
Reviewed By: singhsrb
Differential Revision: D13892198
fbshipit-source-id: 42918d8a775d8328cfad8a6ac0365cb336893d8f
Summary: Add a new `get_file()` method to `MononokeClient` that fetches Mercurial file content from the API server and writes it to a datapack in the cache. This functionality is exposed via the new `hg debuggetfile` debug command, which takes a filenode and file path and fetches the corresponding file.
Differential Revision: D13889829
fbshipit-source-id: 2b68bf114ee72d641de7a1043cca1975e34cf4e6
Summary:
This change is to get DotSlash (https://fb.quip.com/7BbiAmxAK09T)
in the Mercurial release. It renames the build rule from `dotslash` to
`dsl` under the assumption that that determines the name of the binary
to be deployed.
Reviewed By: quark-zju
Differential Revision: D13868779
fbshipit-source-id: dd44d874a60ab85b3dcca79ba5076a6f2fa64135
Summary:
The rename to edenscm broke the test.
(Note: this ignores all push blocking failures!)
Reviewed By: phillco, ikostia
Differential Revision: D13900989
fbshipit-source-id: ad04fcb6889a273bb39901b2288ae1aef74531a6
Summary: Rename this debug command to make it obvious what it does (i.e., perform a health check) and make it print more useful output (i.e., the name of the server for which it performs the health check).
Reviewed By: DurhamG
Differential Revision: D13890867
fbshipit-source-id: 8fc96bcc06d04611a308ecc0b870049936f1cb29
Summary:
Crate adding easy conversions between `http::Uri` and `url::Url`.
Rust has two main types for working with URLs: `http::Uri` and `url::Url`. `http::Uri` comes from the `http` crate, which is supposed to be a set of common types to be used throughout the Rust HTTP ecosystem, to ensure mutual compatibility between different HTTP crates and web frameworks. This is the type that HTTP clients like Hyper expect when specifying URLs.
Unfortunately, `http::Uri` is a very simple type that does not expose any means of mutating or otherwise manipulating the URL. It can only parse URLs from strings, forcing the users to construct URLs via error-prone string concatenation.
In contrast, the `url::Url` comes from the `rust-url` crate from the Servo project. This type does support easily constructing and manipulating URLs, making it very useful for assembling a URL from components.
The only way to convert between the two types is to first convert back to a string, and then re-parse as the desired type. Several issues [have](https://github.com/hyperium/hyper/issues/1219) [been](https://github.com/hyperium/hyper/issues/1102) [raised](https://github.com/hyperium/hyper/issues/1219) about this upstream, but there has been no consensus or action as of yet. To get around the problem for now, this crate adds convenience methods to perform the conversions.
Reviewed By: DurhamG
Differential Revision: D13887403
fbshipit-source-id: ecfaf3ea9d884621493b0fe44a6b5658d10108b4
Summary:
The script tries to extract docstrings of all extensions. It failed to do so
because the extension directory was moved. Fix it by using the default path to
import extensions.
Note: this was half broken before the `edenscm` move because the extensions
cannot be imported correctly so every extension fall backs to "None" in their
help text. This diff fixes that so `man hg` would actually include actual
extension helps. However, some extensions have ill-formatted rst docstrings.
They are fixed in the next diff.
Reviewed By: singhsrb
Differential Revision: D13885567
fbshipit-source-id: 0aba1bc4b0f09fbd8e55d9c8e6ff2587ff6be3f7
Summary:
Original commit changeset: 1cdd43658889
Trying to enable this again.
The details are in the original diff: D13622994
Reviewed By: quark-zju
Differential Revision: D13801916
fbshipit-source-id: a7a1aee6faa0d1db7535dfd3cfab523829c62900
Summary:
`.hg-vendored-crates` is no longer a thing.
Now, the hg vendored crates always match tp2 crates, managed by the
`fbcode/tools/lfs/crates-io.py` script.
Reviewed By: ikostia
Differential Revision: D13873209
fbshipit-source-id: 6b5782b4834c49fa7d88aa1870703138eb9feb00
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:
A while back, as a startup optimization, we started to hard code
the path to the watchman socket in the mercurial config. This meant
that we could avoid running a subprocess for every command.
Today, a chef configuration change was rolled out that caused watchman
to be stopped on all of the corpnet macs with the result being that
all mercurial commands are slow because it never uses and never restarts
watchman.
This diff adds some fallback logic to allow spawning the server in
the case that we have a connection error.
Reviewed By: DurhamG
Differential Revision: D13855696
fbshipit-source-id: 44c0ad36b6e80520912e42bcea9e04f4f165b588
Summary: Some of the revisionstore imports were unused.
Reviewed By: kulshrax
Differential Revision: D13865074
fbshipit-source-id: 79c7c2ba869f2e1d72fa06aac70a4b027367c831
Summary:
Follow up to D13853115 to fix test failures:
- Update an `__import__` statement in dispatch.py to use the new
`edenscm.mercurial` package path.
- Make sure the `__version__.py` file is generated at the correct location by
the buck build files.
Reviewed By: quark-zju
Differential Revision: D13858016
fbshipit-source-id: 54ac4a02274cf921397932e9625f422c5f427623
Summary: Similar to previous diff in this stack, make this type serializable so we can send it as part of an HTTP request.
Reviewed By: singhsrb
Differential Revision: D13858440
fbshipit-source-id: 9173a3e76bcfa6a6600d30ada39d65475f95bc5e
Summary: Make this type serializable so it can be sent as part of an HTTP request. By using Serde, we can easily support a variety of serialization formats without code changes.
Reviewed By: singhsrb
Differential Revision: D13858443
fbshipit-source-id: b6c83f38eaadbb2a28be6d66faf6a3610ede970f
Summary:
The conditional if statement did not prevent the logic inside the
condition from being compiled, which in this case fails on windows. Instead of
using an if, let's just define two functions and conditionally compile the
functions.
Reviewed By: ikostia
Differential Revision: D13855560
fbshipit-source-id: ac417e6bd8fb272106fe8f3b9a8b7db57214ad88
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
Summary:
As a last step towards getting rid of loosefiles, memcache will soon be changed
to produce packfiles. One of the missing piece to achieve is the ability to
read and write packfiles asynchronously, as memcache is purely async.
As a first step, we can wrap the packfile into a blocking context.
Reviewed By: DurhamG
Differential Revision: D13806738
fbshipit-source-id: 2211c2a984a453edbb1647830f7f5fb399a03023
Summary:
As a last step towards getting rid of loosefiles, memcache will soon be changed
to produce packfiles. One of the missing piece to achieve is the ability to
read and write packfiles asynchronously, as memcache is purely async.
As a first step, we can wrap the packfile into a blocking context.
Reviewed By: DurhamG
Differential Revision: D13804184
fbshipit-source-id: 01fcb57af1558feca662b1070969f553c479871a
Summary:
The tempfile rust crates opens the file with RW permissions for the user only,
but once written out to disk, the permissions needs to be readable by everyone.
Unfortunately, rust doesn't have a portable way of doing this, so we have to
resort to using `if cfg!(unix)` conditions for doing this.
Reviewed By: DurhamG
Differential Revision: D13703406
fbshipit-source-id: 688bc679b5c1a7943ceab723c1f649d555b61a7a
Summary:
This allows de-duplicating the logic for setting proper permissions on the
files. Most of the changes is code movement and rustfmt formatting.
Reviewed By: DurhamG
Differential Revision: D13703392
fbshipit-source-id: 28be85ef2d4b440202cf4885e50e62ac3c41f774
Summary:
reconnect logic was not working properly (at least with commitcloud.internal.tfbnw.net:443)
users of hg cloud sync --full could hit it when too many work (more than 5
minutes) happens between get_references and update_references requests.
close()
connect()
seems to work
Reviewed By: suitingtseng
Differential Revision: D13818570
fbshipit-source-id: 6829da60e5b6071a9020c5f7773cd0402df3b294
Summary: This allows us to run pushbackup and cloud sync commands for Read Only Mononoke repos.
Reviewed By: ikostia
Differential Revision: D13804545
fbshipit-source-id: 8026fc4668afc8bb5c2c0a9587ca024e3c6920da
Summary:
Loosefiles are still being fetched from memcache, and thus until we switch
memcache to provide pack files, repack needs to be able to handle loosefiles.
We could either implement the loosefile repack logic in rust, or we could just
let the python code do it. Since we plan on having memcache serve pack files
soon, the second approach is prefered as it result in the least amount of work.
Reviewed By: DurhamG
Differential Revision: D13707886
fbshipit-source-id: 5373b61f9749c158e6dfb026f6b12a7dd2a67802
Summary: Allow the credentials for TLS mutual authentication (namely, the client certificate and private key) to come from separate PEM files. At Facebook, these are usually stored in the same file, but Mercurial's standard TLS configuration options allow these to be configured separately. As such, in order to support the standard options (which will happen in a later diff), provide the ability to handle separate files, but for now just pass the same path for both from Python to Rust.
Reviewed By: markbt
Differential Revision: D13791525
fbshipit-source-id: 556d99d77a4273b9b0bd91cac8940da136088e45
Summary:
Add Python doctests for `util.ring` and fix the bugs in the `pop` and `items`
methods.
Reviewed By: ikostia
Differential Revision: D13803352
fbshipit-source-id: f14acebf4f86da25b9ef5a8238df66cb1a7ebd06
Summary:
The bottom revset can be made faster by switching the order of the
operands to the `&` operation, as this triggers the `_phaseandancestors`
optimization.
Reviewed By: liubov-dmitrieva
Differential Revision: D13800853
fbshipit-source-id: 51d9b65bea1f3a5c8d1ba456d46fe3d3fc03314b
Summary: Use a builder struct rather than a constructor function to configure and initialize new `MononokeClient` instances. Doing it this way is helpful because later in this stack, we'll need to pass a lot of additional configuration to `MononokeClient`; adding all of these items as parameters to the constructor quickly becomes unwieldily. Using a builder keeps the number of parameters in check.
Differential Revision: D13780408
fbshipit-source-id: bfc43ecbe474d5285ae87d4df9cce244a7ff391d
Summary:
Split up the functionality in `MononokeClient` by moving all of the Mononoke API methods to their own separate trait. This maintains a distinction between functionality that is part of the API vs methods for setting up and configuring the client.
Originally, I had tried to avoid using a trait here because of limitations on trait methods (for example, we can't use `impl Trait` for return types). In practice, I don't think this limitation will be an issue since the API exposed by the client needs to be synchronous (since it will be called by FFI bindings to Python), and as such, there shouldn't be any complex Future return types in the API. (The client will still use async code internally, but the external API will be synchronous.)
Differential Revision: D13780089
fbshipit-source-id: 17e80f549d6ac7c41c60b2b8389eb1760531883e
