Summary: This diff makes it possible to relay on the thrift structures from configerator in OSS.
Reviewed By: ahornby
Differential Revision: D20279457
fbshipit-source-id: 39df1c7a6f78b10a0a5bdeeebe476249ab674cc8
Summary:
This shifts the responsibility of mocking all facebook-specific code
to mononoke's sql_ext crate. If OSS code calls into any of that code it will
most likely result in a panic.
Reviewed By: ahornby
Differential Revision: D20247580
fbshipit-source-id: 43f158d91aa32adaa5df6e3786243fb89c9ce961
Summary:
See bottom diff of the stack for overview.
This diff asyncifies the resolver's entrypoint: `resolve` fn, and provides a compatibility shim `resolve_compat` to call from old-style code. Alternatively, we could just do `async move { resolve(...).await }.boxed().compat()` at a callsite. This did not seem too important to do one way or the other, let me know if you feel strongly about it.
Reviewed By: StanislavGlebik
Differential Revision: D20634406
fbshipit-source-id: ee3c73a7a2c65c333e95194bd90ca7330b225011
Summary: See bottom diff of the stack for overview.
Reviewed By: StanislavGlebik
Differential Revision: D20633227
fbshipit-source-id: 16b3f3a764a75261da0585c9724a17853e865681
Summary:
See bottom diff of the stack for overview.
This diff asyncifies `resolve_push`.
Reviewed By: StanislavGlebik
Differential Revision: D20620100
fbshipit-source-id: 1109933e388d9485f42c63638621a7b9227f157f
Summary:
See bottom diff of the stack for overview.
This diff asyncifies `resolve_bookmark_only_pushrebase`.
Reviewed By: StanislavGlebik
Differential Revision: D20610253
fbshipit-source-id: 2a79ac9e8bdca18401ed95d98a0e1b3e92fee4fe
Summary:
See bottom diff of the stack for overview.
This diff asyncifies `return_with_rest_of_bundle`.
Reviewed By: StanislavGlebik
Differential Revision: D20605807
fbshipit-source-id: 0df7d18d06720ff166cdc3e9b981932a819cb0aa
Summary:
See bottom diff of the stack for overview.
This diff asyncifies `next_item`
Reviewed By: StanislavGlebik
Differential Revision: D20605817
fbshipit-source-id: 99fc0100736f0a9307448c6f2ead91da81a531cb
Summary:
See the bottom diff of the stack for overview.
This diff asyncifies two fns: `maybe_save_full_content_bundle2 ` and `is_next_part_pushkey`
Reviewed By: StanislavGlebik
Differential Revision: D20605814
fbshipit-source-id: 1daea901e7620638fa9b8d0b69c18b0ff4e967da
Summary:
See bottom diff of the stack for overview.
This diff asyncifies `maybe_resolve_commonheads` fn.
Reviewed By: StanislavGlebik
Differential Revision: D20605808
fbshipit-source-id: 6b628a4c66970e468839732db8ffb11c961be591
Summary:
See bottom diff of the stack for overview.
This diff asyncifies `maybe_resolve_pushvars` fn.
Reviewed By: StanislavGlebik
Differential Revision: D20605812
fbshipit-source-id: e68f9d878a294a9980e53b104aa1035c0d47ae65
Summary:
See bottom diff of the stack for overview.
This diff asyncifies `maybe_resolve_changegroup`.
Reviewed By: StanislavGlebik
Differential Revision: D20605810
fbshipit-source-id: fbf5e9d93b355dfa23a3a7657edb96b033535f9d
Summary:
See bottom diff of the stack for overview.
This diff asyncifies `ensure_stream_finished` fn.
Reviewed By: StanislavGlebik
Differential Revision: D20605805
fbshipit-source-id: 853a6d5d1afeee0f8f841eec51302fb3ceb701c7
Summary:
See bottom diff of the stack for motivation.
This diff asyncifies `resolver_multiple_parts` and `maybe_resolve_pushkey` functions.
Reviewed By: StanislavGlebik
Differential Revision: D20605815
fbshipit-source-id: 90768f4495632ec83b79ca9fcf982b0ec5c277cf
Summary:
In rare situations users end up manually deleting or removing their `.eden`
state directory without ever killing their running `edenfs` process. This can
leave this old process running indefinitely despite the fact that it's state
directory is no longer present (or has perhaps even been replaced with new
data).
This updates edenfs to periodically check if its lock file is still valid, and
quit if it isn't. This will help prevent old `edenfs` processes from running
indefinitely after their state directory is no longer valid.
Reviewed By: wez
Differential Revision: D20613841
fbshipit-source-id: d9a3a1e7e9b05806e086e794ebbc36e1cc71831a
Summary:
One of the main drawback of the current version of repack is that it writes
back the data to a packfile, making it hard to change file format. Currently, 2
file format changes are ongoing: moving away from packfiles entirely, and
moving from having LFS pointers stored in the packfiles, to a separate storage.
While an ad-hoc solution could be designed for this purpose, repack can
fullfill this goal easily by simply writing to the ContentStore, the
configuration of the ContentStore will then decide where this data will
be written into.
The main drawback of this code is the unfortunate added duplication of code.
I'm sure there is a way to avoid it by having new traits, I decided against it
for now from a code readability point of view.
Reviewed By: DurhamG
Differential Revision: D20567118
fbshipit-source-id: d67282dae31db93739e50f8cc64f9ecce92d2d30
Summary: There is no need to pass the path twice, once is enough.
Reviewed By: DurhamG
Differential Revision: D20567117
fbshipit-source-id: 169a088aa7558b4c25f8fbdecfe59bdd0d7575ef
Summary:
While the primary (for now) way of addressing an LFS blob is via its sha256,
being able to address them via different hash schemes (sha1 for Eden/Buck,
blake2, etc) will be helpful down the line. Thus, let's store a HashMap of
ContentHash in the pointer store.
Reviewed By: DurhamG
Differential Revision: D20560197
fbshipit-source-id: 8bdc4fc4cd7fc19c7eed6a27d11953c4eedf9195
Summary:
The hgcache will soon contain an LFS subdirectory, this is uninteresting for
most of the tests, let's change them a bit so they only look at the packs
subdirectory.
With this, enabling remotefilelog.useruststore only has 2 failures. One due a
difference in handling corrupt data, with the ruststore being more explicit
that some data is missing instead of a generic "stream ended unexpectedly". And
the other due to some ordering difference when dealing with LFS data. The
latter will go away with the new LFS implementation.
Reviewed By: DurhamG
Differential Revision: D20543146
fbshipit-source-id: 09c76cacfb4687fd699b82cdf5057665ac6bd521
Summary: No locking is required for this one due to being loose files on disk.
Reviewed By: DurhamG
Differential Revision: D20522890
fbshipit-source-id: 72b7ebc063060a89f54976a1128977a3b7501053
Summary:
In preparation for building a single binary that can run inside and
outside of the corp environment, restructure EdenMain to allow
selecting the implementation at runtime.
Reviewed By: simpkins
Differential Revision: D20613464
fbshipit-source-id: 56dbf006f6e9fd74af9c490a47c832a5367d3d3d
Summary:
See bottom diff of the stack for overview.
This diff asyncifies `resolve_b2xtreegroup2`.
Reviewed By: StanislavGlebik
Differential Revision: D20605806
fbshipit-source-id: 2e667d19f2014d051d25a74353e9ebd2e6a93c72
Summary:
See bottom diff of the stack for the overview.
This particular diff asyncifies the `maybe_resolve_infinitepush_bookmarks` fn.
Reviewed By: StanislavGlebik
Differential Revision: D20605816
fbshipit-source-id: 11b6e9c5dd7423bcc4ecc988efd581a3e970ccdc
Summary:
See the bottom diff of the stack for the overview.
This diff specifically migrates the `upload_changesets` function.
Reviewed By: StanislavGlebik
Differential Revision: D20605809
fbshipit-source-id: 36a11a72fb828d494bd18c7737e2682cb3b7cb9a
Summary:
See D20605813 for the overview of the stack.
This diff migrates a few leaf functions.
Reviewed By: krallin
Differential Revision: D20605811
fbshipit-source-id: 2f5d5e5fba3a00afd61a4eb58c505658ac82943a
Summary:
A wider goal of this stack is to migrate `repo_client/unbundle/src/resolver.rs` to async/await and new futures.
The approach is as follows:
- rename old futures upon import into `OldFuture`, `OldBoxFuture`, etc. so that it is easily visible where we use what [this diff]
- implement a bunch of mechanical conversions of continuation-passing-style code to the imperative async/await based code without worrying about clones-vs-references or excessive boxification. Keep individual diffs as small and as mechanical as possible, so that it is easier to review.
- once the `resolve` fn is migrated, introduce `resolve_compat`, which is used from `repo_client/client/src/mod.rs`
- then go through the codebase and see where we can remove clones of resolver/ctx and excessive `boxed()/boxify()` if any are left
Note: `Bundle2` is an `OldStream` and I postpone its migration till the high-level structure of the `resolver.rs` is migrated, since the main value is in allowing imperative-style code in the file
Reviewed By: krallin
Differential Revision: D20605813
fbshipit-source-id: 32255d7b3573f87f74a496e6e40b842e553242a7
Summary:
SCS log accepts two dates/timestamps to filter history by the commit creation time. Each timestamp is a `i64` and zero or negative timestamp still represents a pretty valid time in past.
The time filters are pretty expensive: they require sequential changeset info fetching and checking the date.
It turned out that some of the requests have time filters but seem not meaning it: their both after and before timestamps equals to zero. And there are lots of such queries: https://fburl.com/scuba/mononoke_scs_server/g345na72. This cause SCS log traverse the whole history for a path, which turns into hours of fetching cs infos and fastlog batches.
I've decided to consider a valid timestamp only the timestamp greater than 0: only after 1970-01-01 00:00:00 UTC.
Reviewed By: StanislavGlebik
Differential Revision: D20670210
fbshipit-source-id: f59c425779a37ecac489dbba2ed3fd547987ee62
Summary: Enable the CLI tests on macOS when run with Buck.
Reviewed By: wez
Differential Revision: D20524347
fbshipit-source-id: cf3e302256b6b0e6958999cf83c5be5d48f65907
Summary:
In the open source and macOS builds of EdenFS, enable Thrift function
statistics.
Reviewed By: simpkins
Differential Revision: D20550819
fbshipit-source-id: bb6fe2f1f413b89f344cb3725a7382fdb3d50a5d
Summary:
Fix a problem with the handling of short reads
which would result in returning trailing garbage.
Implement setting timeouts.
Implement sendall (not strictly needly, but added here
for symmetry with the pywatchman equivalent code.
Reviewed By: chadaustin
Differential Revision: D20584508
fbshipit-source-id: a27a7392b3335458c5e56a91376220ab045ad30b
Summary:
This enforces certain selective pull logic in core. Namely, rewrite `pull -r X`
to `pull -r X -B master`.
Unlike selectivepull in remotenames, `pull` (pulls everything) won't be
rewritten to `pull -B master` (which pulls less commits and names).
Therefore this change always adds more commits to pull, and therefore should not
break existing users. Eventually we want the "not pulling everything" behavior,
but right now this just fixes `pull -r X` to also update important remote names.
Reviewed By: markbt
Differential Revision: D20531121
fbshipit-source-id: af457b5ddb1265b61956eb2ee6afb7b7208293e0
Summary:
fixes up some functions to avoid narrowing warnings
and others to adopt `folly::to_narrow` to accept them.
This reduces the number of warnings in the windows build.
Reviewed By: chadaustin
Differential Revision: D20562026
fbshipit-source-id: f18ba50f914e142415d1efefebc6297e8c68d38e
Summary:
I noticed that the output was `{backing_repo}` in a couple
of user reports, rather than the path to the backing repo.
Reviewed By: genevievehelsel
Differential Revision: D20669756
fbshipit-source-id: c9f1dbb4f4b2ad3de03c54f1e3cb5f688ee433ac
Summary:
This is the first step of asyncifying the `bonsai_verify`
command. For this diff I'm doing a literal translation: convert a big
legacy future into a big async future.
Reviewed By: farnz
Differential Revision: D20632015
fbshipit-source-id: 9e663d36c25c6f0c90db88ff84e550fd04bb2ab7
Summary:
Changed all of the high-level interfaces and most of the
code to use new-style futures.
Reviewed By: farnz
Differential Revision: D20625467
fbshipit-source-id: e85a87f9acdaaf7671617f3f76e66a316884977c
Summary: Now we have functions to get selectivepull names in core. Use that instead.
Reviewed By: markbt
Differential Revision: D20531118
fbshipit-source-id: a0c20c491baf1b0ad71e80f870703bb4b983f19c
Summary: This makes it possible for core to always pull related bookmarks.
Reviewed By: markbt
Differential Revision: D20531120
fbshipit-source-id: 52f0834b517e03567e240f57616370d79a227abe
Summary:
This makes it possible to use template like `{remotenames}` or revset like
`remotenames()` without enabling the remotename extension.
Rarely used revsets like `upstream()` and `pushed()` are not moved.
Reviewed By: markbt
Differential Revision: D20529360
fbshipit-source-id: ea95b3324f974e112909cdd79ce662940a4f9b7c
Summary:
This makes it possible to resolve remotenames without enabling the remotenames
extension.
The config check `if repo.ui.configbool("remotenames", "bookmarks")` is dropped
intentionally as we only use remotenames for bookmarks, not named branches.
Since this only enables resolving more names, without disabling or changing
other features, and the remotename namespace priority is lower than local
bookmarks (ex. if a local `master` exists, then `master` will be using the
local bookmark, not the hoisted remote name), it should not cause breaking
changes.
Reviewed By: markbt
Differential Revision: D20529359
fbshipit-source-id: 4126faee1bb7f43ba547fab05dd6197b2e65c1fc
Summary:
This moves part of remotenames that provides the `repo._remotenames` object to
core. It should not change behaviors but merely makes `repo._remotenames`
available in core.
Reviewed By: markbt
Differential Revision: D20529358
fbshipit-source-id: 11c8538a0190101b09a4cb082018e73643a257e2
Summary:
All the `blobimport.rs` logic has now been asyncified. We still have
a `.compat()` sandwich for now around the `.traced()` call that we can
get rid of when tracing::Traced moves over to the new API
Reviewed By: farnz
Differential Revision: D20615191
fbshipit-source-id: da3f8a66b18d0dbef6895f6f08952b563f7f8680
Summary:
This diff creates a new async function `run_blobimport` to handle
most of the logic that was formerly in `main`, so that we can use
async-style code.
Reviewed By: farnz
Differential Revision: D20614860
fbshipit-source-id: bd8d3e230f53201d2dec53a3033f048572f2a67e