Summary: This is an sqlite equivalent of what exists in xdb now.
Reviewed By: krallin
Differential Revision: D21427621
fbshipit-source-id: 7024fbf7a8773c4465d2e6ee327aadeaf87cb213
Summary:
Implement autopull so non-automation `hg pull -r Dxxxx`, `hg up Dxxxx` will
pull `Dxxxx` automatically.
Since we now autopull the commits, error messages are removed. The old code
actually causes issues because it will raise at `"D1234" in repo`, which is
a surprise to many code paths, including the revset autopull logic, which
uses `x in repo` to decide whether `x` is unknown.
Note `hg pull -r Dxxxx` is not using the revset layer and needs to be handled
separately. It works for hg servers right now because the server can translate
`Dxxx` to a commit hash. It probably does not work for a Mononoke server.
Reviewed By: sfilipco
Differential Revision: D21320626
fbshipit-source-id: 939abe12e3a9a8ed5ca7ed29bb4f90fb39e7674a
Summary:
Change the interface to return infallible `Optional[node]` instead of fallible
`List[rev]`. In the next diff, we're going to use the 'node' information to
implement autopull.
Reviewed By: sfilipco
Differential Revision: D21320628
fbshipit-source-id: 6f7c070faba667cc85313cc78d6149c787ca8593
Summary:
Currently, phrevset picks the "successor" that has the maximum revision
number. That depends on the assumption that larger revision numbers
are modified last. Howevver, that's not always true with commit cloud sync. For example, in my repo I have D21179514 modified from 63768bf43
to 684612d5d. Phabricator has 63768bf43. Local successor is 684612d5d,
but the revision number of 684612d5d is smaller than 63768bf43:
quark@devvm1939 ~/hg/edenscm/hgext % hg log -r 'D21179514'
changeset: 63768bf436d01982a8d42ce97160ac6d9ae2cdad D21179514
user: Jun Wu <quark@fb.com>
date: Wed, 22 Apr 2020 09:45:50 -0700
summary: [hg] commitcloud: log metalog root during update references
quark@devvm1939 ~/hg/edenscm/hgext % lhg log -r 'D21179514'
changeset: 684612d5d606b01c224889f2b3f87aff7b93db49 D21179514 (@)
user: Jun Wu <quark@fb.com>
date: Wed, 22 Apr 2020 10:10:37 -0700
summary: [hg] commitcloud: log metalog root during update references
quark@devvm1939 ~/hg/edenscm/hgext % lhg log -r 'successors(63768bf436d0198
2a8d42ce97160ac6d9ae2cdad)' -T '{node} {rev}\n'
684612d5d606b01c224889f2b3f87aff7b93db49 76718
63768bf436d01982a8d42ce97160ac6d9ae2cdad 95363
Improve it by actually prefer selecting a non-obsoleted successor.
Reviewed By: sfilipco
Differential Revision: D21267552
fbshipit-source-id: d43d72a7c273c55af70bb41ad967fff0c78a452a
Summary: This is more efficient (if pullattempts have high chance to succeed).
Reviewed By: sfilipco
Differential Revision: D21320627
fbshipit-source-id: a2166f5a59f98c7d705c806b9d152ceb9981f3be
Summary:
Make it so that the autopull functions just describe what to do (using the
`pullattempt` struct) instead of having the side effect directly. This will be
useful in multiple cases:
- The actual autopull logic becomes easier to implement.
- The revset autopull layer can merge `pullattempt`s to fetch things in one go.
- The `pull -r` logic can reuse the `pullattempt`s to translate what to pull
(ex. from `D1234` to a commit hash).
This has subtle changes that multiple "remote"s are no longer properly
supported. That is probably fine in our production use-cases but we might
want to revisit if we want to support remotes "properly". Currently, this
greatly simplifies things due to the fact that "infinitepush" or
"infinitepushbookmark" have to be used in certain cases.
Reviewed By: sfilipco
Differential Revision: D21320633
fbshipit-source-id: e38b68abf69a34a97431685aa7ab0d2fe022fda8
Summary: Add a way for extensions to register how to auto pull unknown names.
Reviewed By: sfilipco
Differential Revision: D21320630
fbshipit-source-id: d20e11cff83b8a7e15a5085b0508a3e5bef305c3
Summary:
We're going to make autopull more complicated. Move it to a separate module as
it is not directly related to revset.
Reviewed By: sfilipco
Differential Revision: D21320631
fbshipit-source-id: fe60bc53ebf1c75f8bf66156805cbe2801fe6532
Summary:
The revset optimization makes unknown names harder to extract. For example,
`(or (list "a" "b" "c"))` will be optimized to `(_list "a\0b\0c")` and it
becomes harder to extract `"a"`, `"b"`, and `"c"`.
Move the unknown name extraction logic to before the optimization step to solve
it.
Reviewed By: sfilipco
Differential Revision: D21320632
fbshipit-source-id: 3a25f1cf4aab0449be6952113d622f29b1c0b631
Summary:
vs2017 is not able to compile the static assertion in KeySpace.cpp.
Previously we thought that this would be resolved in a later release of vs2017
but now that is here it is clear that it hasn't been fixed.
This commit pushes the version requirement to vs2019 (see
https://dev.to/yumetodo/list-of-mscver-and-mscfullver-8nd for a mapping between
product versions and compiler versions), but we cannot build with vs2019
because folly and rangev3 don't compile with vs2019, so this assertion (heh!)
has literally not been tested.
This commit also fixes up an oversight in the gating logic: the intent is that
we perform the assertion on all systems except known broken MSVC. We were
accidentally restricting it to later versions of MSVC.
Reviewed By: simpkins
Differential Revision: D21432890
fbshipit-source-id: e11ffccc53bf8dffdf2db45ad4f3cf199b1cc70d
Summary:
This allows us to understand what config is used during a transaction.
For example, is `selectivepull` enabled during a `pull`?
Reviewed By: DurhamG
Differential Revision: D21222146
fbshipit-source-id: a8c82f2b02e9657885947a706f728e28b1bfc1e2
Summary:
We're seeing deadlocks where if the process forks (like in a update
worker) while a background python thread is holding the progress lock, it can
cause a deadlock in the forked process if the thread ever tries to access the
progress bar.
To fix it, let's invalidate the engine if the process forks.
Reviewed By: xavierd
Differential Revision: D21415152
fbshipit-source-id: 75607dd2c1ed122b3a9df68d359ba9dcdde78a77
Summary:
There was a bug in scrub blobstore that caused failures while traversing the
fsnodes.
If all blobstores returned None, then we need to return None and not fail as we
do now. So the situation we ran into was:
1) fsnodes is not derived, all blobstore return None
2) Previously it returned the error, which later checked in
https://fburl.com/diffusion/mhhhnkxv - this check makes sure there's no entry
with the same key on the queue. However by that time fsnodes might already be
derived and someone else might insert a new entry in the blobstore and in the
queue. This would return an error to the client.
The fix here is to not fail if all blobstores returned None
Reviewed By: ahornby
Differential Revision: D21405418
fbshipit-source-id: 21fe130ce65a0087c408a5014e5b108c7ce8fe6c
Summary:
A number of repo names are used quite frequently. Let's use an enum to
prevent typos and make things cleaner.
Reviewed By: quark-zju
Differential Revision: D21365036
fbshipit-source-id: 1d3d681443df181e9076f5ee87029ae61124a486
Summary: Cover as much as remining code with `Cargo.toml`s, for the rest create an exlusion list in the autocargo config.
Reviewed By: krallin
Differential Revision: D21383620
fbshipit-source-id: 64cc78a38ce0ec482966f32a2963ab4939e20eba
Summary: Covering repo_listener and microwave plus some final touch and we have a buildable Mononoke binary.
Reviewed By: krallin
Differential Revision: D21379008
fbshipit-source-id: cca3fbb53b90ce6d2c3f3ced7717404d6b04dd51
Summary:
There are few related changes included in this diff:
- backsyncer is made public
- stubs for SessionContext::is_quicksand and scuba_ext::ScribeClientImplementation
- mononoke/hgproto is made buildable
Reviewed By: krallin
Differential Revision: D21330608
fbshipit-source-id: bf0a3c6f930cbbab28508e680a8ed7a0f10031e5
Summary:
- Change get return value for `Blobstore` from `BlobstoreBytes` to `BlobstoreGetData` which include `ctime` metadata
- Update the call sites and tests broken due to this change
- Change `ScrubHandler::on_repair` to accept metadata and log ctime
- `Fileblob` and `Manifoldblob` attach the ctime metadata
- Tests for fileblob in `mononoke:blobstore-test` and integration test `test-walker-scrub-blobstore.t`
- Make cachelib based caching use `BlobstoreGetData`
Reviewed By: ahornby
Differential Revision: D21094023
fbshipit-source-id: dc597e888eac2098c0e50d06e80ee180b4f3e069
Summary: Instead of having `HgBackingStore` fetch blobs separately, we now try to read from hgcache and fetch from `HgImporter` as batches.
Reviewed By: chadaustin
Differential Revision: D20903245
fbshipit-source-id: d8e404d6765f1bcbacbf2a39f83eab0a351a3fe0
Summary: This diff makes `HgImportRequestQueue` to be able to return multiple requests in the queue at once.
Reviewed By: chadaustin
Differential Revision: D20197070
fbshipit-source-id: 8cff1780d6e56321a756d30ac0e9b9d5d319c049
Summary: The life of a request is only able to be finished with one of the method. So we can instead having the tracker destroyed when the future is resolved.
Reviewed By: chadaustin
Differential Revision: D20995819
fbshipit-source-id: 5dac2f762513b5d0bcacaab7d0669fc8fdb61e80
Summary:
Readability improvements.
`HgQueuedBackingStore` will need to call these functions individually.
Reviewed By: chadaustin
Differential Revision: D20683321
fbshipit-source-id: 9a9bd766c34559048bd0971f17304090abbb2774
Summary:
During a graceful restart, while the fuse mount is not handling
requests, avoid a possible deadlock between the edenfs, hg
debugedenimporthelper, and watchman processes.
See the comment in HgImporter.cpp.
Reviewed By: fanzeyi
Differential Revision: D21342275
fbshipit-source-id: df8fb5df5d5cd1490e88b42054b34cbb2acdb692
Summary: This bug got in while iterating the original Diff. It should only be returning empty when the blob does not exist locally.
Reviewed By: xavierd
Differential Revision: D21417659
fbshipit-source-id: 676e22313ab4a024af5341d8c99797fc062bd293
Summary:
Instead of trying to maintain two hgrc.dynamic's for shared repositories,
let's just always use the one in the shared repo. In the long term we may be
able to get rid of the working-copy-specific hgrc entirely.
This does remove the ability to dynamically configure individual working copies.
That could be useful in cases where we have both eden and non-eden pointed at
the same repository, but I don't think we rely on this at the moment.
Reviewed By: quark-zju
Differential Revision: D21333564
fbshipit-source-id: c1fb86af183ec6dc5d973cf45d71419bda5514fb
Summary: Let's log the mismatches to scuba so we can track them down.
Reviewed By: quark-zju
Differential Revision: D21313255
fbshipit-source-id: ee79c9504a80ebe5b21849c0eae5993b65eaff28
Summary:
In a future diff we want to log information about configuration
mismatches. In order to do that, we need to be able to call ui.log before
extensions are setup. Let's move the ui.log sampling logic into core so it can
be called before extension setup.
Reviewed By: quark-zju
Differential Revision: D21313257
fbshipit-source-id: fe1c0f572720c17e7398f2a4fa7082ef8fb59536
Summary:
Adds python logic for validating the dynamic configs. Any dynamic
configs that don't match the given list of rc files will be reported and removed
Reviewed By: quark-zju
Differential Revision: D21310919
fbshipit-source-id: 07f584bba990f1b01347dfbc285e3ca814fe5c5a
Summary:
Adds .hg/hgrc.dynamic to the default load path, before .hg/hgrc though,
so it can be override.
Reviewed By: quark-zju
Differential Revision: D21310921
fbshipit-source-id: 288a2a2ba671943a9f8532489c29e819f9d891e1
Summary:
On Windows, the following pseudo code:
int fd = open("file");
struct stat st;
fstat(fd, &st);
Will have a different st_dev than the following code:
struct stat st;
stat("file", &st);
Since the FileChangeMonitor uses st_dev as a way to compare if a file
changed, the config is always reloaded.
For our use case, the filesize and its mtime should be enough to know if the
configuration changed, so let's only use these 2 on Windows.
Reviewed By: wez
Differential Revision: D21312679
fbshipit-source-id: f08b3eb7d6037f5d88ece82efe3a5437b1954ba2
Summary:
Only the mtime test had to be disabled due to getMetadata not being tracked
on Windows.
Reviewed By: wez
Differential Revision: D21312680
fbshipit-source-id: 5678956ed2b8b45b38d44c459557161aa6fd222e
Summary:
Fairly straightforward, one change to the test was necessary as reading an
unlinked file cannot be done on Windows.
Reviewed By: wez
Differential Revision: D21312681
fbshipit-source-id: c8cca5eeca7825983176ef618007c514b8e02140
Summary:
This brings it closer to folly::writeFile which should help in avoiding ifdef
whenever we want to use it.
Reviewed By: wez
Differential Revision: D21319020
fbshipit-source-id: 80fbf7fba671b18b5ef68375910e1a2a8869f590
Summary:
Our internal git dependency got upgraded, so we need to upgrade our
Cargo.toml version. Unfortunately this doesn't seem to have any test coverage?
Reviewed By: singhsrb
Differential Revision: D21410241
fbshipit-source-id: 64fe7f39a9c93aa5d97ce095ee1641c1cc6ed365
Summary:
On Windows calling `connect()` on an AF_UNIX socket path that does not exist
creates a file at that location. This is problematic as it now prevents
servers from binding to that path. Even if the server attempts to remove the
file in order to bind, clients attempting to call `connect()` can race with it
and make binding fail.
This updates our client connection code check to see if the file exists before
attempting to call `connect()`. This can still race with a server that is
trying to remove an old socket and re-bind, but it at least makes the race
less likely to happen.
Reviewed By: genevievehelsel
Differential Revision: D21410571
fbshipit-source-id: 3df63b19b40b25be98108246186a48a379cdab28
Summary:
The formatter is broken, it prints to stdout which breaks json output,
and it's questionable whether we want a new line printed to the user for every
200k files downloaded.
Reviewed By: quark-zju
Differential Revision: D21409529
fbshipit-source-id: 2a5d94f8fcc62dbe25f0aae5453e4664c49fdcb2
Summary:
When we log to Scuba, we need to truncate the `msg` field if it's too long, or
we might be missing log entries in Scuba. I put this behind a tunable so we can, well,
tune it.
Reviewed By: farnz
Differential Revision: D21405959
fbshipit-source-id: 08f0d3491d1a9728b0ca9221436dee2e8f1a17eb
Summary:
The name of a checkout is not a public concept, so refer to the
checkout's path.
Reviewed By: genevievehelsel
Differential Revision: D21393208
fbshipit-source-id: 4c014a6f65515f4632f2dffe5d563d0ee859dda0
Summary:
When I want FUSE stats, I never run `eden stats io`. To unify the
command language, rename `io` to `fuse` and `latency` to
`fuse-latency`, to match `thrift` and `thrift-latency`.
Leave aliases in place in the off chance someone cares.
Reviewed By: genevievehelsel
Differential Revision: D21392931
fbshipit-source-id: 843c1c85ea0aa162ba167f251f0f2cde5a389e72
Summary:
`eden stats memory` was never useful because it shows system
statistics which you can get better from `top`, `htop`, or `atop`.
Reviewed By: genevievehelsel
Differential Revision: D21392737
fbshipit-source-id: 010021b8a97bd8ba8ac289d906acc3c3ecd10768
Summary: So the linter will stop nagging at my changes to this file.
Reviewed By: wez
Differential Revision: D21396011
fbshipit-source-id: dbc3479637cca83aa1a11ff94a9033dfa42fc2a6
Summary:
Talked with xavierd last week and we can use LocalStore's `get_missing` to determine if a blob is present locally. In this way we can prevent the backingstore crate from accidentally asking EdenAPI for a blob, so better control at EdenFS level.
With this change, we can use this function at the time where a blob import request is created with confidence that this should be short cheap call.
This diff should not change any behavior or performance.
Reviewed By: xavierd
Differential Revision: D21391959
fbshipit-source-id: fd31687da1e048262cb4eae2974cab6d8915a76d
Summary:
This test is flaky right now, but it's not clear why. I'm also unable to repro.
Let's add more logging.
Reviewed By: StanislavGlebik
Differential Revision: D21405284
fbshipit-source-id: 3ce5768066091de61e62339286410a6223d251d5
Summary:
When doing discovery, for repos with long master lines and infrequent
branches, picking a random set of sample commits could result in not picking the
master, and therefore having to do very long commit graph traversals to check
ancestors against the other samples.
To prevent this, let's pick the N most recent commits instead of a random
sample. This should generally get the master commit into our sample.
Reviewed By: quark-zju
Differential Revision: D21394302
fbshipit-source-id: f4b8110cd126b90553ec624e48cab0b590e124fb
Summary: Making a trait out of TimeWindowCounter will help with providing different implementations of load limiting for OSS and FB.
Reviewed By: krallin
Differential Revision: D21329265
fbshipit-source-id: 7f317f8e9118493f3dcbadb0519eaff565cbd882
Summary:
This is helpful. Also, while in there, I removed an error that wasn't used at
all.
Reviewed By: StanislavGlebik
Differential Revision: D21399489
fbshipit-source-id: 0e5ef20b842afa9ffc0bb8530c48eb48339c558e
Summary:
We have a number of error enums that wrap an existing errors, but fail to
register the underlying error as a `#[source]`. This results in truncated
context chains when we print the error. This fixes that. It also removes a
bunch of manual `From` implementation that can be provided by thiserror's
`#[from]`.
This also required updating the `Display` implementation for those errors. I've
opted for not printing the underlying error, since the context chain will
include it. This does mean that if we print one of those errors without the
context chain (i.e. `{}` as opposed to `{:#}` or `{:?}`), then we'll lose out a
bit of context. That said, this should be OK, as we really shouldn't ever being
do this, because we'd be missing the rest of the chain anyways.
Reviewed By: StanislavGlebik
Differential Revision: D21399490
fbshipit-source-id: a970a7ef0a9404e51ea3b59d783ceb7bf33f7328
Summary:
This removes our own (Mononoke's) implementation of failure chains, and instead
replaces them with usage of Anyhow. This doesn't appear to be used anywhere
besides Mononoke.
The historical motivation for failure chains was to make context introspectable
back when we were using Failure. However, we're not using Failure anymore, and
Anyhow does that out of the box with its `context` method, which you can
downcast to the original error or any of the context instances:
https://docs.rs/anyhow/1.0.28/anyhow/trait.Context.html#effect-on-downcasting
Reviewed By: StanislavGlebik
Differential Revision: D21384015
fbshipit-source-id: 1dc08b4b38edf8f9a2c69a1e1572d385c7063dbe
Summary:
I'm going to send a diff to get rid of failure chains, and the LFS Server
actually uses that quite a bit. Let's make sure we don't affect the error
rendering there.
Reviewed By: StanislavGlebik
Differential Revision: D21383032
fbshipit-source-id: e0ec9c88760e7fd48d39fa1570efd1870a9ef532
Summary:
Looks like this broke yesterday. There was a Reindeer update yesterday IIRC, so
I'm guessing that's the cause. In any case, this is easy to fix forward.
Reviewed By: farnz
Differential Revision: D21399830
fbshipit-source-id: 5cf33411e089a8c675a8b3fdf7b6ae5ae267058d
Summary:
If config.toml exists but does not contain a valid storage engine,
edenfs would fail to start. Now, it will set a default value and write
the updated config file.
Reviewed By: simpkins
Differential Revision: D19671453
fbshipit-source-id: 32f19dbed2be02bec2a96e1349dca6e7038b9301
Summary:
Addressing issues simpkins brought up on D21207287 when we upgraded and introduced some pyre bugs.
Temporarily upgrading just this project, once we resolve some sandcastle capacity issues we'll release this via another global upgrade in fbcode.
Reviewed By: simpkins
Differential Revision: D21316793
fbshipit-source-id: f0c79f53d97f7182e7d8fe6e081c58ef53ce0c9a
Summary: When we create directory at certain places, we want these directories to be shared between different users on the same machine. This Diff uses the previously added `create_shared_dir` function to create these directories.
Reviewed By: xavierd
Differential Revision: D21322776
fbshipit-source-id: 5af01d0fc79c8d2bc5f946c105d74935ff92daf2
Summary:
All the changes we need are now in stable, so use the stable crates.io version.
I also had to do coordinated updates of git2 and rustsec to make sure they're
all using the same version of libgit2-sys. This had a couple of little API changes which affected our code:
- mononoke gitimport (krallin)
- linttool (zertosh) (BTW the old code had some very dubious lifetime stuff - a signature of the form `fn foo<'a>(&self) -> Thing<'a>` never makes any sense - output lifetimes should always be derived from the params)
Similarly, toml-rs needed to be updated because there's now a hard dependency on 0.5.6.
msdkland[rust_cargo]
msdkland[rust_reindeer]
Reviewed By: dtolnay
Differential Revision: D21311180
fbshipit-source-id: 82083c8f2bb8523e70cbe99dc0a630c4bc67a505
Summary: These docs are all EdenFS specific so move them into the fs/ directory.
Reviewed By: genevievehelsel
Differential Revision: D21329620
fbshipit-source-id: 4090ed4ca371d01ea98e06ad6ce8f434c0660962
Summary:
The MSVC compiler complains that it doesn't have the full definition of
PrivHelper, causing the build to fail. Include the right header to fix this.
Reviewed By: genevievehelsel
Differential Revision: D21381946
fbshipit-source-id: 0d0389ee8db44a36786973404c38487a94e8c4df
Summary:
Previously we only included `basic_test.py` and `hg/status_test.py` in the
integration tests during CMake-based builds. This updates the code to now
include all of the test files, with just a few exclusions based on platform
type and what dependencies were available at build time.
Reviewed By: wez
Differential Revision: D21239912
fbshipit-source-id: b8826d249a6323ac3bcc555c9ceba54a4cbcfde9
Summary:
10 of the integration tests fail on Ubuntu. For now simply blacklist them
from running on non-RedHat-based distributions.
Reviewed By: wez
Differential Revision: D21332629
fbshipit-source-id: 3fadb74bb31e89092177afaa01ddc7f6bcd0f9de
Summary:
Add a new IntegrationTestCase base class that checks the test blacklist during
`setUp()`, and update a few remaining test classes that did not derive from
`EdenTestCase` to derive from this.
Also drop the method name argument from the `skip_test_if_blacklisted()`
function, since we can get this from the existing test case argument.
Reviewed By: genevievehelsel
Differential Revision: D21340539
fbshipit-source-id: d4fc125f119d74ab923c2cc3c9070b86c582c87e
Summary:
Run `env` as `/usr/bin/env` instead of `/bin/env`
This command is typically installed in `/usr/bin`. Recent RedHat releases
replaced `/bin/ with a symlink to `/usr/bin`, allowing this command to work
when invoked as `/bin/env`, but this isn't true on all distributions, such as
Ubuntu.
Reviewed By: chadaustin
Differential Revision: D21340540
fbshipit-source-id: d7588f8c90e9a86a0cb31fd3ab3a9067aa6e79ea
Summary: These third-party includes are edenfs-specific, so move them into eden/fs/
Reviewed By: simpkins
Differential Revision: D21314642
fbshipit-source-id: c52b0a00d5080934e1f07e4cd55373602f2f6b0a
Summary: These benchmarks are edenfs-specific, so move them into /eden/fs/
Reviewed By: genevievehelsel
Differential Revision: D21314464
fbshipit-source-id: 1dcf6adfbdea1394f222de4d462397ea531ced00
Summary:
This updates repo_client to log when hooks finished, and how many were rejecte,
if any. This required a bit of refactoring to avoid iterating twice over
whether hooks are rejected or not (and instead just filter-maps outcomes to a
rejection), but it's probably for the better since it removes a bit of
un-necessary cloning (notably of the hook name).
Reviewed By: farnz
Differential Revision: D21379690
fbshipit-source-id: 53c8368d3871620ec61db76dc35b47dd17276ac4
Summary:
This adds support for running Gitimport with `--readonly-storage`. The way we
do this is by masking the various storages we use (blobstore, changesets,
bonsai).
Reviewed By: markbt
Differential Revision: D21347939
fbshipit-source-id: 68084ba0d812dc200776c761afdfe41bab9a6d82
Summary:
The original gitimport wasn't really designed for concurrency, since it did
commits one by one. With this update, we can now derive Bonsais from multiple
commits in parallel, and use multiple threads to communicate with the Git
repository (which is actually somewhat expensive when that's all we do).
We also store Bonsais iteratively. There is a bit of extra work that could be
done also here by saving Bonsais asynchronously to the Blobstore, and inserting
a single batch in Changesets once we're finished.
Reviewed By: farnz
Differential Revision: D21347941
fbshipit-source-id: e0ea86bf4d164599df1370844d3f0301d1031801
Summary:
This adds support for deriving commits within a range in gitimport, which gets
us one step closer to resumable gitimport. The primary goal of this is to
evaluate whether using Gitimport for Configerator might be suitable.
Differential Revision: D21347942
fbshipit-source-id: aa3177466e389ceb675328999ccf836f29912698
Summary:
This adds some basic functionality for deriving hg manifests in gitimport. I'd
like to add this to do some correctness testing on importing Git manifests from
Configerator.
Differential Revision: D21347940
fbshipit-source-id: 6f819fa8a62b3088fb163138fc23910b8f2ff3ce
Summary:
- Use the same case consistently
- Log even when pushrebase fails
Reviewed By: farnz
Differential Revision: D21378033
fbshipit-source-id: 062e986151086476db9100e3d9c71aa702661032
Summary:
Currently we need to specify which derived data we need to derive, however they
are already specified in the configerator configs. Let's just read it from
there.
That means that we no longer need to update tw spec to add new derived data types - we'll just need to add them to configerator and restart the backfiller.
Reviewed By: krallin
Differential Revision: D21378640
fbshipit-source-id: f97c3f0b8bb6dbd23d5a50f479ecfccbebd33897
Summary: Making a trait out of LoadLimiter will help with providing different implementations of load limiting for OSS and FB.
Reviewed By: farnz
Differential Revision: D21302819
fbshipit-source-id: 1b982a367aa7126ca5d7772e4a2406dabbe9e13b
Summary: A result of `configerator-thrift-updater scm/mononoke/repos/repos.thrift`
Reviewed By: farnz
Differential Revision: D21350982
fbshipit-source-id: b3344c99c6f53c727ea16ebc0f81f90527de103d
Summary:
D21316793 is blocked from landing because there are a few targets in eden that are running pyre via buck targets integration.
We can't do custom version overrides for projects that are using a mix of local configurations and buck integration, because buck doesn't provide an interface for setting the equivalent pyre version override.
We're moving away from buck targets integration for pyre across the board, and I've run a codemod over the project to clean up all of the buck typing integration (including some residual mypy) as well as updated type ignores / fixmes accordingly.
Let me know if you have any concerns; upon skimming it looks like most changes are either converting `type: ignore`s into fixmes, or removing `type: ignores`.
Reviewed By: dkgi
Differential Revision: D21343093
fbshipit-source-id: 5ee1436377eb526c0a679fb821c42e07cbca52a5
Summary:
When running Eden as a service, CreateProcess will pop up a console window for every new console based process. Eden fs spawns hg import helper process which will create console windows. It doesn't impact the functionality but is a bad user experience.
Passing the CREATE_NO_WINDOW flag to CreatePeocess will suppress the console Window.
Reviewed By: wez
Differential Revision: D21361412
fbshipit-source-id: 96ecfa2d9ca811287cdc60ba1c4632f16f38340e
Summary: This enables the Edenfs to run as a console application.
Reviewed By: wez
Differential Revision: D21241794
fbshipit-source-id: 704e8488b680ac90f11e9eabef704879a395d7e0
Summary: By default the Eden on Windows will run as a service. It should be installed as a Windows service by the installer to work properly.
Reviewed By: wez
Differential Revision: D21241597
fbshipit-source-id: 2bcbd518d274d829bee5616d266c542f3fcc4b16
Summary:
ConEmu tries to normalize 256 colors to 16 colors but its normalization logic
is buggy. For example, color196 gets normalized to green instead of red. See
the attached picture of ConEmu and its debug real console.
{F235735030}
Reviewed By: markbt, ikostia
Differential Revision: D21311443
fbshipit-source-id: cb6db07d6b10a7365e33f4aa8f5f3f61f90c8e69
Summary:
While EdenFS does not use a separate privhelper process on Windows, it still
defines a stub PrivHelper class. However, this class was previously defined
in a separate win/utils/Stub.h header file, which led to awkward `#ifdef`s to
include the correct platform-specific header file.
This diff moves the definition of the dummy PrivHelper class in Windows into
the same `PrivHelper.h` header file used on POSIX platforms. This results in
a few more `ifdef`s in the PrivHelper files, but fewer `ifdef`s in the calling
code, and will make it easier to start unifying more of the `EdenMain` logic
on Windows and non-Windows platforms.
Reviewed By: xavierd
Differential Revision: D21332568
fbshipit-source-id: c63bf2b4a8b7e767d7db7dcda28675f735c23bf8
Summary:
The kernel has some legacy logic to attempt to clear the setuid and
setgid mode bits upon writes, but it is racy and disabled by default
in libfuse3. Now that we don't support setgid and setuid bits at all,
opt out of the legacy kernel behavior.
Reviewed By: wez
Differential Revision: D21334075
fbshipit-source-id: bdef12c1958a5e9bd2649c2bcb54975b0b4e78d6
Summary:
We'll be adding a bunch of Facebook specific configuration and values
here. Let's move it to someplace not open source.
Reviewed By: quark-zju
Differential Revision: D21241038
fbshipit-source-id: 2ac9cdce40b1b46f15f171d9d1f6b6692dcd29bf
Summary:
Implements an ensure_location_supersets function who's goal is to
verify that a given config location specifies the exact same configs as a given
set of other locations. Any inconsistencies are removed from the config and
reported to the caller.
This will be used to ensure our dynamic configs match our existing rc file
configs exactly, before we delete the file configs.
Reviewed By: quark-zju
Differential Revision: D21240837
fbshipit-source-id: e2c8ec054a3696d2cf02e65c212ad886c5117253
Summary:
The `parents` template currently returns "meaningfulparents". This sometimes
returns the null revision as the second parent, making templates think this is a
merge commit when it is not. Make sure we filter this out.
Reviewed By: quark-zju
Differential Revision: D21347776
fbshipit-source-id: af83fd5cff381850ac39d97b5b2f4c77033fe2fb
Summary:
Make all the things that only Lua hooks needed (hook type etc) optional.
With this done, configs can be cleaned up to not contain redundant data.
Reviewed By: ikostia
Differential Revision: D21349614
fbshipit-source-id: 1c72c2082b8c002e3feb41d1d720a41d21afaae5
Summary:
In the initial stages of the windows port we had
problems building rocksdb on windows, so we disabled it.
These days we're able to build it and detect it--we even
require it in the cmake code, but hadn't gotten around
to telling the rest of the code that we can use it.
This commit re-enables it in the build but leaves sqlite
as the default engine until we're able to perform some
benchmarking.
Rocksdb itself has some build issues on Windows; it doesn't
use cmake to locate dependencies, so even though we built
snappy it doesn't know how to find it without modifying the
source:
https://github.com/facebook/rocksdb/blob/master/thirdparty.inc#L4
For that reason, we disable the use of Snappy in the Windows build.
However, in the version of rocksdb that we were using, it would
default to trying to use Snappy even though it wasn't compiled in
and throw an exception.
I've upgraded to a newer version of rocksdb that will simply not
use compression if no compression was enabled at build time.
Given that we mostly store relatively small objects, I'm assuming
that the lack of compression is fine for now.
Reviewed By: xavierd
Differential Revision: D21319896
fbshipit-source-id: 2a2d06d4bd5382706e9220f9b4a2de99dc18311d
Summary: `cargo autocargo` should normally produce no changes on `master`. The features of the `log` crate was updated in D21303891 without re-running autocargo. This fixes it.
Reviewed By: dtolnay
Differential Revision: D21349799
fbshipit-source-id: ce487bc5989e179673297350249593103b4d34dd
Summary:
Now we download files in 200K chunks, and it might be confusing - it's unclear
whether hg is making any progress or not.
This diff makes it clearer.
Note I'm not printing progress before first fetch to avoid breaking the tests
Reviewed By: farnz
Differential Revision: D21348756
fbshipit-source-id: 05e5169114adf2b99a74b37d933755a644214a42
Summary: Mercurial Infinitepush normally records received bundles into the `forwardfillerqueue`, which is later tailed by the commit cloud `forwardfiller` in order be replayed onto Mononoke. Now I am adding a reverse filler, which means that we will have two such queues and sync in two directions. Therefore, in order to avoid infinite loops we need to distinguish cross-backend bundle replay from genuine pushes. I propose to use `crossbackendsync` bundle2 param to indicate that no recording is needed.
Reviewed By: krallin
Differential Revision: D21255446
fbshipit-source-id: 70f6efe1331bd3c7fd3aca61d486d350d93086dc
Summary:
Previously we weren't showing help at all when running "hg cloud --help". This
diff should fix it
Reviewed By: ikostia
Differential Revision: D21347825
fbshipit-source-id: 1d9d11e2f9fe18a03b5d2cd8bd316fe9a218347c
Summary: Let's make it tunable, more context in D21300885
Reviewed By: ikostia, krallin
Differential Revision: D21347636
fbshipit-source-id: 4bc91effdd212a3f5c4a0c3d4952f52a1cf417d7
Summary:
Path elements longer than 255 bytes cannot be materialized on most filesystems,
so allowing them isn't very useful.
We can't normally receive a push for this (because the client would have to
have the file on their isk), but they could get created through a
specially-crafted bundle or accidentally through a Thrift API (e.g. create
commit in SCS).
Reviewed By: farnz
Differential Revision: D21328145
fbshipit-source-id: cb32d6df0aa60863665a651f1a33c69c75c6a880
Summary:
In vs-code if you have a well-formed url you can command-click it
to open it, e.g., when you see it in your terminal. But this URL is not
well-formed because it's missing the protocol. So let's add it.
Reviewed By: quark-zju
Differential Revision: D21336742
fbshipit-source-id: dd2de2d5177d3a2542c4a22f0099f28b97c79d06
Summary:
Update the Windows code to use the normal StartupLogger.h and .cpp files.
Previously the Windows code defined its own separate StartupLogger.h file.
The class declaration looked largely like a copy of the POSIX
DaemonStartupLogger code, but most of the methods were not actually defined
anywhere. The actual functionality appears identical to the POSIX
ForegroundStartupLogger, so this code just switches to using that in most
cases.
Reviewed By: xavierd
Differential Revision: D21332570
fbshipit-source-id: 0585a38d8f37dc93459d380aa277082c35cbadfc
Summary:
Currently, Mononoke's configs are loaded at startup and only refreshed
during restart. There are some exceptions to this, including throttling limits.
Other Mononoke services (such as the LFS server) have their own implementations
of hot reloadable configs, however there isn't a universally agreed upon method.
Static configs makes it hard to roll out features gradually and safely. If a
bad config option is enabled, it can't be rectified until the entire tier is
restarted. However, Mononoke's code is structured with static configs in mind
and doesn't support hot reloading. Changing this would require a lot of work
(imagine trying to swap out blobstore configs during run time) and wouldn't
necessarily provide much benefit.
Instead, add a subset of hot reloadable configs called tunables. Tunables are
accessible from anywhere in the code and are cheap to read as they only require
reading an atomic value. This means that they can be used even in hot code
paths.
Currently tunables support reloading boolean values and i64s. In the future,
I'd like to expand tunables to include more functionality, such as a rollout
percentage.
The `--tunables-config` flag points to a configerator spec that exports a
Tunables thrift struct. This allows differents tiers and Mononoke services to
have their own tunables. If this isn't provided, `MononokeTunables::default()`
will be used.
This diff adds a proc_macro that will generate the relevant `get` and `update`
methods for the fields added to a struct which derives `Tunables`. This struct is
then stored in a `once_cell` and can be accessed using `tunables::tunables()`.
To add a new tunable, add a field to the `MononokeTunables` struct that is of
type `AtomicBool` or `AtomicI64`. Update the relevant tunables configerator
config to include your new field, with the exact same name.
Removing a tunable from `MononokeTunables` is fine, as is removing a tunable
from configerator.
If the `--tunables-config` path isn't passed, then a default tunables config
located at `scm/mononoke/tunables/default` will be loaded. There is also the
`--disable-tunables` flag that won't load anything from configerator, it
will instead use the `Tunable` struct's `default()` method to initialise it.
This is useful in integration tests.
Reviewed By: StanislavGlebik
Differential Revision: D21177252
fbshipit-source-id: 02a93c1ceee99066019b23d81ea308e4c565d371
Summary:
FUSE_HANDLE_KILLPRIV expects that any write() call is handled by
clearing the setuid and setgid bits in the userspace. To avoid
implementing that behavior, disallow setting setuid or setgid in the
first place.
Reviewed By: xavierd
Differential Revision: D21333703
fbshipit-source-id: eb084ee8b00afe74c0da26e41c32c2cb742723da
Summary: I'm about to add a new parameter to `scribe_commit_queue`; first asyncify it to modernise
Reviewed By: krallin
Differential Revision: D21288044
fbshipit-source-id: d1a4bb052b3c055383dd9d9df5fe36d61b14bdfe
Summary: If the bundle file has 1G in size, we probably don't want to waste 1G of memory just to see that it is too big.
Reviewed By: markbt
Differential Revision: D21177359
fbshipit-source-id: 026b5ab40e6dbddba3d7142a8e34256d127bf82c
Summary:
Building on the previous two commits, this adds a test which performs the following steps:
- does an infintiepush push to a Mercurial server
- looks into the `forwardfillerqueue`
- runs commitcloud forwardfiller's `fill-one` to replay the bundle to Mononoke
- verifies that this action causes the commit to appear in Mononoke
As this test uses `getdb.sh` from Mercurial test suite, it needs to be whitelisted from network blackholing (Note: we whitelist mononoke tests, which run with `--mysql` automatically, but this one is different, so we need to add it manually. See bottom diff of the stack for why we don't use `--mysql` and ephemeral shards here).
Reviewed By: krallin
Differential Revision: D21325071
fbshipit-source-id: d4d6cbdb10a2bcf955ee371278bf2bbbd5f5122c
Summary:
Microwave doesn't normally allow writes, which can cause cache warmup to fail
if master has underived commits. So, let's go back in bookmarks history to
whatever is most recent and derived. We can do so using the existing logic we
use in the warm bookmarks cache.
Reviewed By: farnz
Differential Revision: D21325485
fbshipit-source-id: 11e758cd512a22e02704ac34458fead18c284c20
Summary:
This updates cache_warmup to new futures, since I'd like to do a little bit of
work in there. This also changes a bit of functionality: until now we were
roundtripping through a hg changeset id un-necessarily so that updates it to
just use the bcs id instead.
Reviewed By: mitrandir77
Differential Revision: D21325484
fbshipit-source-id: 4d296c5fbe7c21dda681aed4ed9c572a38246893
Summary:
Instead of multiple linear array scans to determine the type of a FUSE
request, use a single lookup table. This is a small optimization, but
it makes the code a bit nicer too.
Reviewed By: wez
Differential Revision: D21314720
fbshipit-source-id: 5b6700ad5bb8e353da1e457de1533e6a626e8f68
Summary:
Google Benchmark is easier to use, has more built-in functionality,
and more accurate default behavior than Folly Benchmark, so switch
EdenFS to use it.;
Reviewed By: simpkins
Differential Revision: D20273672
fbshipit-source-id: c90c49878592620a83d2821ed4bc75c20e599a75
Summary:
Cloning a repository with selectivepull enabled temporarily disables
selectivepull for the duration of the initial pull so that we can get a
streaming clone.
Once this is done, hide all of the commits in the repository by clearing the
visible heads. Selective pull will then populate the remote bookmarks with the
public heads that we do want.
Reviewed By: quark-zju
Differential Revision: D21301037
fbshipit-source-id: 565ae50439ed5405ce940a5675caeba912fe7083
Summary: If a scratch remotebookmark points to a draft commit that is not available locally (i.e., has been hidden on a different machine), then don't pull it into the local repository. Instead, just omit the remote bookmark.
Reviewed By: quark-zju
Differential Revision: D21287886
fbshipit-source-id: 84e7c6b52250709f7c88b07fccdbb61e044370c8
Summary:
Selective pull subscripts are lost during a push. This is because
`remotenames.expush` calls `selectivepullbookmarknames` with the
remote, not the remote name.
`remotenames.exclone` does the same, but in that case there is
no need for the remote name as the destination can't have any
subscriptions other than the default set.
Reviewed By: quark-zju
Differential Revision: D21283029
fbshipit-source-id: 52c2e7e301b8e95b4a252cbfe2ad9de168e81044
Summary:
Commit cloud remote bookmarks sync has several edge cases that don't work correctly.
This test demonstrates some that we will fix.
Reviewed By: quark-zju
Differential Revision: D21283028
fbshipit-source-id: 4e746476a0f3bf0ca7d7088f510451632a2ee075
Summary:
This is a fix after D21067809 broke the mononoke_api unittests and was not caught by sandcastle.
Prior to this change if `ctx.identities` were None then the permission was unconditionally denied, even when the permission checker is set to always_allow. After this change if the identities is None then the permission_checker is called with empty identity set thus making unit tests work properly.
Reviewed By: krallin
Differential Revision: D21324038
fbshipit-source-id: 1edd5fd2af6731d43cab06324b4d9fc02882c09e
Summary:
The systemd binary is installed in a different location on Debian-based
distributions (e.g., Ubuntu) from RedHat-based distributions. Update the
integration tests to look in both places.
Reviewed By: wez
Differential Revision: D21297591
fbshipit-source-id: 67e5a698080205b8624c1f38aa49e75c20b6a28c
Summary:
Our CMakeLists.txt file requests `ctest` to pass in a `CMAKE_SOURCE_DIR`
environment variable when running our integration tests via `ctest`. However
if a developer manually invokes the test binary this environment variable may
not be set.
For convenience, this updates the code to try looking at the default location
where getdeps will have put the source relative to the build directory (at
least for internal builds using shipit-converted fbsource sources).
Reviewed By: wez
Differential Revision: D21307807
fbshipit-source-id: d747c50d79d2d378721b68b18c256d5363e41f26
Summary:
Update the integration tests to attempt to find the Mercurial config files
from the source directory even in CMake-based builds. This directory will be
available when doing an internal build from fbsource via getdeps.py
If this directory isn't present (e.g., on a build from the github repository)
we will still fall back to using the Mercurial configuration files installed
on the system. In that case I did update the code to use the correct system
configuration path on Windows.
Reviewed By: wez
Differential Revision: D21307808
fbshipit-source-id: 917ba5e8548fed999fb06a29324be125cec83cac
Summary:
Remove the requirement that the `--edenfs` argument flag must be passed in
when invoking the `edenfs` daemon.
This flag was added in D12927803 to help provide a better error message if
users accidentally ran `edenfs` when they really mean to run `edenfsctl`.
However, this shouldn't really be a major problem any more: on Linux and Mac
we now install `edenfs` in a `libexec` subdirectory instead of `bin`, so it
should not be in most user's `$PATH` by default any more. Additionally we
also verify that no other unexpected arguments have been supplied. Prior to
D12927803 the `edenfs` binary would ignore unexpected arguments, making the
error messages more confusing when users tried to run it with `edenfsctl`
subcommand arguments.
One motivation for changing this now is that the Windows version of `edenfs`
does not require this flag, and it is desirable to remove this behavior
discrepancy. Rather than making this flag required on Windows it seems fine
to just drop the requirement on Mac & Linux.
Reviewed By: wez
Differential Revision: D21297159
fbshipit-source-id: e24bd694dadc036cd31dead287ae2c1184747822
Summary:
Update the tests that derive from `ServiceTestCaseBase` to honor the test
blacklist, and to also skip if we cannot run the `fake_edenfs` utility. This
latter check primarily fails when we cannot run `sudo` non-interactively
without a password prompt.
Most of the other tests were already honoring blacklist through the
`EdenTestCase` base class, but `ServiceTestCaseBase` does not derive from
`EdenTestCase`.
Reviewed By: wez
Differential Revision: D21297160
fbshipit-source-id: 5044e9939bbe487c09aa96021166c95f02fb376e
Summary:
Move the `UserInfo` code from `fuse/privhelper` to `utils`, and also unify the
POSIX and Windows implementations of this class.
This code was originally put in the `fuse/privhelper` directory since it was
written at the same time as the privhelper. However, it's really a
lower-level library that doesn't depend on FUSE or any of the other code in
the `fuse/` subdirectory.
Reviewed By: wez
Differential Revision: D21296594
fbshipit-source-id: f58682f6ce86bba0328472c491bb4c0dc3370319
Summary:
Merge react and userprofile_shell into master, rewrite profile to use react and revert changes to p page
```
Reviewed By: markbt
Differential Revision: D21285297
fbshipit-source-id: f60006738af068982a25fa368fd260ba5b7f3781
Summary: The changes to server/context, gotham_ext and the code that depends on them are the only reminding places where aclchecker is used directly and it is not easy to split this diff to convert them separately.
Reviewed By: krallin
Differential Revision: D21067809
fbshipit-source-id: a041ab141caa6fe6871e1fda6013e33f1f09bc56
Summary:
Enable the unit tests under eden/fs/utils on Windows.
This does comment out a few tests related to `AbsolutePath` that are broken on
Windows. The AbsolutePath constructor does not enforce that the input path is
actually absolute. Additionally the `canonicalPath()` function ends up doing
weird things and returning paths that start with `/` followed by a drive
letter (e.g., `/C:/foo`). These issues should ideally be addressed in
subsequent diffs.
Reviewed By: xavierd
Differential Revision: D21239886
fbshipit-source-id: ef08d62353ba83b96d9fd79bd4636f4a0f961373
Summary:
When connecting to Mononoke, it's possible for the connection to hang
for a while before ultimately failing. This is a poor experience for users.
Add a timeout, such that hgcli will only wait for 15 seconds before reporting a
failure back to the user.
Reviewed By: krallin
Differential Revision: D21281472
fbshipit-source-id: 6329a108a1ae3ec337d74529a80e0fcd74e02231
Summary: Add a README to provide an overview of the walker for reviewers and maintainers
Reviewed By: ikostia
Differential Revision: D21250280
fbshipit-source-id: 9fd7cd3a076a276de904b8ae5372fc1c0c28458b
Summary:
The operation originally wanted to operate on the fuse `Attr`
structure which we don't have on Windows, so I repurposed the
`InodeBase::getattr` into `InodeBase::stat` and moved the conversion
of `struct stat` to `Dispatcher::Attr` to the `EdenDispatcher::getattr`
method (and a couple of other adhoc places that were doing a similar
conversion).
Reviewed By: chadaustin
Differential Revision: D20562459
fbshipit-source-id: 6b538110038352e9b5590fcb5ff5c33fe84ac1d8
Summary:
The only change I had to make was due to the fact that MSVC wasn't smart
enough to realize that the shift value couldn't be negative, so a manual
folly::to_unsigned was added to silence the warnings.
Reviewed By: simpkins
Differential Revision: D21268634
fbshipit-source-id: e65f15d58d5ea23bfa6796bab23cf1f5c2e7c12c
Summary:
On Windows, the expected refcount is one less than what it is on Linux, due
to the .eden directory not being present.
Reviewed By: simpkins
Differential Revision: D21268203
fbshipit-source-id: 91cfe742fa4d576917d552964d9541dc68ad2c75
Summary: Fix permission issues we are seeing with the latest Mercurial release.
Reviewed By: xavierd
Differential Revision: D21294499
fbshipit-source-id: bcfb13dd005258b2e3b74fa281dbd8df36133ef6
Summary: I thought it would be helpful to introduce and `eden uptime` command, especially with automated graceful restart on the way. This prints it in human readable format, later on if for some reason automation would like to use this, a flag could be added that allows for custom formatting. Also, this can be added to `eden rage` output later.
Reviewed By: chadaustin
Differential Revision: D21260800
fbshipit-source-id: 3f9a4f8d6264dfc38bd15c024a0209f7eeb912fa
Summary:
Previously, for logging the value of unexpected enum values, we wrote
`static_cast<int>`. Given enumerations can have any integral type
backing them, this was somewhat inaccurate. Instead, introduce an
explicit enumValue function which returns a value of the appropriate
underlying type.
Reviewed By: genevievehelsel
Differential Revision: D20975176
fbshipit-source-id: 0bb5b0d2f68f8fe9d68e4c6a847d59ae0997d0df
Summary:
D21074489 adds metrics for pending FUSE requests, this cleans up the display for
pending requests.
This removes the max duration of pending requests for FUSE requests since this
data is not available (it is not measured by the FUSE library).
Reviewed By: chadaustin
Differential Revision: D21074746
fbshipit-source-id: e5585ec091aa5fd5499deee2d8be89f47f769a6a
