Summary:
As titled. This is needed by OpenBCM, and in future, possibly by other
manifests as well.
Reviewed By: wez
Differential Revision: D18759807
fbshipit-source-id: d445dfa382cea4bf96443ab9889926a4abbf0757
Summary:
These are not currently used by mercurial and are superseded
by the newer more general `watchman_client` crate on crates.io:
https://docs.rs/watchman_client/0.2.0/watchman_client/
Some of the implementation of that crate was based on the work I'm
removing here.
I was going to update hg_watchman_client to be implemented in terms
of the new crate, but since it isn't used and it would only be a thin
wrapper, I figure that it is best to delete this code instead so that
we can integrate it in terms of the new API when we're ready.
Reviewed By: singhsrb
Differential Revision: D18777161
fbshipit-source-id: efacb749e6d35ff4cc1fdc7d99cdca9ed42c9cfe
Summary:
`edenfsctl` on macOS is not returning the status code correctly when build with `make-client.py`.
We should be using [`zipapp_main`](https://fburl.com/diffusion/3eot1k7a) that uses `sys.exit` to propagate the exit code from [`main`](https://fburl.com/diffusion/k7t8vqmx).
Reviewed By: simpkins
Differential Revision: D18772986
fbshipit-source-id: 1714be9665b0779d30e5c86fb1e498466fee56f9
Summary:
Since it's not calling conduit anymore we can remove all conduit related
functions.
Reviewed By: quark-zju
Differential Revision: D18733121
fbshipit-source-id: 20a6022d9ac7ae6e9afea2791a8daac57cefb22c
Summary:
conduit is going away, phabricator team wants us to stop using
it in hg.
Reviewed By: quark-zju
Differential Revision: D18732257
fbshipit-source-id: c4faf83e36af80fc616e91adede141ba12de5446
Summary: conduit is going away, phabricator team wants us to stop using it in hg
Reviewed By: quark-zju
Differential Revision: D18727399
fbshipit-source-id: c208f5fec5fefd83aa37629b56d2bbaa2532d30e
Summary:
It would be nice if the insert method would give back the path that
it failed to insert.
Reviewed By: dtolnay
Differential Revision: D18739978
fbshipit-source-id: 4c16d09750ade2f01397161129c31bcf0059a957
Summary:
The Mercurial code has the bad habbit of inserting files in what can
appear impossible locations. Sometimes files with directory names and
sometimes directories in file locations. This happens because the initial
code would do additions before deletions on Manifest implementations that
were rudimentary. As soon as we introduce validation various code paths
surface.
I tried to fix the codepaths that modify manifests but it's a losing game.
I fixed the issue that appeared in tests and a couple of issues people
reported but more situations crop up.
This is giving up on the python code.
Reviewed By: quark-zju
Differential Revision: D18737678
fbshipit-source-id: 0c97128ff67e5ba2334942b6afc404aa64a2e5f4
Summary:
In NFS v4.x, flock ends up inheriting some semantics of fcntl,
including that write locks can only be created against file handles
opened for O_WRONLY or O_RDWR.
This diff changes the mode of 'lockpath' to O_RDWR to solve this.
Reviewed By: simpkins
Differential Revision: D18714734
fbshipit-source-id: 84ba4a6a5de034a4942b1ca3aa8b0c92f882ce38
Summary:
This is an update to the fbcode_builder codebase to allow setting up the python virtualenv with python dependencies installed. I've included wheel and cython (with a pinned version to 0.28.6 which is the only version that works with thriftpy3 at the moment, due to https://github.com/cython/cython/issues/2985) as standard packages since these are required by some of our top-level dependencies (folly and thrift)
As far as I know, there are no other projects that use PYTHON_VENV at the moment except LogDevice so the impact should be minimal.
Reviewed By: lucaspmelo
Differential Revision: D18758383
fbshipit-source-id: 264941311c5e3a19dc4ef2bb78c9a1baa34dfd8c
Summary:
`path = ...` is enough. This should resolve the following build issues:
error: failed to select a version for the requirement `serde_bser = "^0.1.0"`
candidate versions found which didn't match: 0.2.0
location searched: ...
required by package `watchman_client v0.1.0 (...)
... which is depended on by `hg_watchman_client v0.1.0 (...)`
Reviewed By: lukaspiatkowski
Differential Revision: D18738176
fbshipit-source-id: 725840895a8e988b35000a48cf92018b14cb4dee
Summary: The cargo builder will be used to verify if an opensource Rust project passes Cargo build, test and (optionally) documentation build.
Reviewed By: markbt
Differential Revision: D18636934
fbshipit-source-id: e982e6a017eb32913e2994e7457c8add2e9d6b95
Summary:
Since bookmarks are stored in svfs, track it in metalog for better transaction
support.
This affects some transaction / rollback behaviors. Since our plan is to remove
`hg rollback` eventually, the compatibility is intentionally broken.
Reviewed By: xavierd
Differential Revision: D18538147
fbshipit-source-id: 6070772a4bce88d3808547207f5df194696b1b52
Summary:
Existing tools (ex. shell complete script) still read from
`.hg/store/{remotenames,bookmarks}`. Be compatible with them by double writing
content to both metalog and filesystem. Metalog is the source of truth for hg.
Reviewed By: xavierd
Differential Revision: D18524106
fbshipit-source-id: c37bc86b7443bba1b65735f29243767650b22ecd
Summary:
Similar to D17199834, by moving 'bookmarks' from localvfs and sharedvfs to
storevfs, we can make it part of metalog and get better transaction support.
Reviewed By: xavierd
Differential Revision: D18524104
fbshipit-source-id: ae148c1f02fc83b5c2d73102ecab39ff223ea5df
Summary:
I'm going to move `bookmarks` to "metalog". So operating on the `.hg/bookmarks`
file no longer works.
Reviewed By: xavierd
Differential Revision: D18524105
fbshipit-source-id: dc31b13e1acc171d2e8b32cdfea7028faf6dc4d3
Summary:
Right now `bookmarks` is stored at both "local" vfs and the "shared" vfs.
In an upcoming change I'd like to move bookmarks to the "metalog" to get
better transaction. Therefore make it always shared.
The shared bookmark feature is turned on by default. Assuming nobody manually
turns it off, production hosts all have shared bookmark turned on.
Reviewed By: simpkins
Differential Revision: D18524103
fbshipit-source-id: 3160146f357dd01f2d78f5d2f4a14838f8f12a94
Summary:
We have seen cases on Windows where the hg process gets stuck in
CreateToolhelp32Snapshot. Let's be defensive and always exit the loop.
Reviewed By: singhsrb
Differential Revision: D18729720
fbshipit-source-id: fb8602ce231eec01b6b42c6759849d56e5db2030
Summary:
The only valid place that metalog can be changed is inside a transaction, since
it's transaction.{close,abort} that writes or discards metalog changes.
In other words, metalog should not be changed during A, B, or C:
|<- A ->|<----------- repo lock --------->|
|<- B ->|<- transaction ->|<- C ->|
Add detection for them.
Reviewed By: xavierd
Differential Revision: D18538143
fbshipit-source-id: 036286ed32a897fe3ce0a91c1e3c848cc6167b1d
Summary:
This helps test if there are uncommitted changes. It can help detecting
programming errors. For example, is metalog changed before starting a
transaction?
Reviewed By: xavierd
Differential Revision: D18538148
fbshipit-source-id: 9c82838d8174e6a93fde7108503a025660191cbf
Summary:
Before this diff, metalog has a same lifetime as repo.svfs and never gets
reloaded or dropped. That is problematic in case external processes also
make changes, ex. running `hg amend` in `histedit exec`.
pid 1> histedit action foo (a single transaction, metalog loaded here)
pid 1> histedit action exec ... (a single transaction)
pid 2> hg amend (changes metalog)
pid 1> histedit action bar (cannot perform this action because metalog has
conflicts!)
This is why test-mutation.t didn't work with metalog.
Fix it by discarding metalog state at transaction/lock boundary (enter/exit).
The next two diffs add checks so we wouldn't discard uncommitted data silently.
Reviewed By: xavierd
Differential Revision: D18519995
fbshipit-source-id: ceb030362d66ad4be142e81accb82a4afa67f305
Summary: This resolves ProgrammingErrors detected by a later change.
Reviewed By: xavierd
Differential Revision: D18538145
fbshipit-source-id: 650e956707af6024457cdc7dabf516d087ad03cd
Summary:
The current `commit` code path errors out without telling much about what
conflicts are. Improve it by showing what are actually conflicting, and allows
users to replace the resolver function to do customized merges.
Reviewed By: xavierd
Differential Revision: D18519996
fbshipit-source-id: 78f42ada1df45659783ce1eba30a19f6fc6b3b62
Summary:
Those tests will crash `run-tests.py` because `svn` is unknown to `hghave`.
Alternatively we can revert `hghave` changes in D18088850. But it seems there
is little interest in converting svn repos using the convert extension.
Reviewed By: singhsrb
Differential Revision: D18713922
fbshipit-source-id: 1a70b3d5d0fe8d02cc0549eabeb609ab1d9c12e6
Summary:
This diff fixes `CMakeLists.txt` to enable building `openr` tests using CMake:
1. It adds `add_openr_test` CMake function that adds executable target, registers it as test, links it with bunch of libraries like GTest and GMock, etc...
2. There is no `openr/tests/OpenrModuleTestBase.cpp` anywhere in the source tree, so this commit replaces it with `openr/common/Flags.cpp`.
Reviewed By: jstrizich
Differential Revision: D18584028
fbshipit-source-id: 07d854ef98d0d2509889a08ad042a371101a2825
Summary:
"outstanding merge conflicts" is not a helpful message to inexperienced users.
Print out commands to get more context.
Reviewed By: simpkins
Differential Revision: D18535010
fbshipit-source-id: 035ec9f3d79bf04a997ee907469f2e3d749a1d0e
Summary: Some commits in AOSP have empty fields for author/committer email addresses.
Reviewed By: tchebb
Differential Revision: D18661778
fbshipit-source-id: e975392da677879d598eb9fc77558251a55c2f23
