Summary: This project has custom stubs that contain type errors. We'll need to fix them so the switch to new Pyre backend won't create any regressions.
Reviewed By: dkgi
Differential Revision: D29953374
fbshipit-source-id: f54d25682d6b01eed4867eab6823e29ddb95e754
Summary:
We need to set the infinitepush path too so that the Mercurial autopull code
won't try to pull from Mononoke
Reviewed By: genevievehelsel
Differential Revision: D29943227
fbshipit-source-id: a67dbfe97e7ab46dee885d9ec91a4d194dc2bd37
Summary:
High-level goal of this diff:
We have a problem in long_running_request_queue - if a tw job dies in the
middle of processing a request then this request will never be picked up by any
other job, and will never be completed.
The idea of the fix is fairly simple - while a job is executing a request it
needs to constantly update inprogress_last_updated_at field with the current
timestamp. In case a job dies then other jobs would notice that timestamp
hasn't been updated for a while and mark this job as "new" again, so that
somebody else can pick it up.
Note that it obviously doesn't prevent all possible race conditions - the worker
might just be too slow and not update the inprogress timestamp in time, but
that race condition we'd handle on other layers i.e. our worker guarantees that
every request will be executed at least once, but it doesn't guarantee that it will
be executed exactly once.
Now a few notes about implementation:
1) I intentionally separated methods for finding abandoned requests, and marking them new again. I did so to make it easier to log which requests where abandoned (logging will come in the next diffs).
2) My original idea (D29821091) had an additional field called execution_uuid, which would be changed each time a new worker claims a request. In the end I decided it's not worth it - while execution_uuid can reduce the likelyhood of two workers running at the same time, it doesn't eliminate it completely. So I decided that execution_uuid doesn't really gives us much.
3) It's possible that there will be two workers will be executing the same request and update the same inprogress_last_updated_at field. As I mentioned above, this is expected, and request implementation needs to handle it gracefully.
Reviewed By: krallin
Differential Revision: D29845826
fbshipit-source-id: 9285805c163b57d22a1936f85783154f6f41df2f
Summary:
Currently they got zeros by default, but having NULL here seems like a nicer
option.
Reviewed By: krallin
Differential Revision: D29846254
fbshipit-source-id: 981d979055eca91594ef81f0d6dc4ba571a2e8be
Summary:
This option would let us tell that a given bookmark (or bookmarks if they are
specified via a regex) is allowed to move only if it stays an ancestor of a
given bookmark.
Note - this is a sev followup, and we intend to use it for */stable bookmarks
(e.g. fbcode/stable, fbsource/stable etc). They are always intended to be an
ancestor of master
Reviewed By: krallin
Differential Revision: D29878144
fbshipit-source-id: a5ce08a09328e6a19af4d233c1a273a5e620b9ce
Summary:
When rebasing during "amend --to", we were mixing up file contents when there was more than a single merged file in a three way merge. The cause was a lambda within a loop closing over a loop variable.
Also suppress the "merging some/file.c" message if the result of the three way merge is identical to the "local" version of the file. It is confusing to see unexpected "merging" messages.
Reviewed By: DurhamG
Differential Revision: D29940097
fbshipit-source-id: 5a4c19279c14209268359939fbf91f164c791b2e
Summary:
TSAN complains that pipes_ is read and written in different threads without
proper synchronization. To avoid this, we can simply close the FileDescriptor
without removing it from the pipes map as this achieve the same result: it
notifies the reader that the endpoint is closed.
Differential Revision: D29924043
fbshipit-source-id: be92630799bb5c78089dbe85f9c2f02f937300bc
Summary:
## High level goal
This stack aims to add a way to upload commits directly using the bonsai format via edenapi, instead of using the hg format and converting on server.
The reason this is necessary is that snapshots will be uploaded on bonsai format directly, as hg format doesn't support them. So this is a stepping stone to do that, first being implemented on commit cloud upload, as that code already uses eden api, and later will be used by the snapshotting commands.
## This diff
This diff fixes the bonsai changeset upload endpoint, by making it get the changesets for the parents using hgids by querying them from blobrepo. The inner map is not enough as the bottom of the stack always has a parent outside of the stack.
Reviewed By: liubov-dmitrieva
Differential Revision: D29880356
fbshipit-source-id: b6b5428159e8c74f5a910f39dadb98aa10c78542
Summary:
## High level goal
This stack aims to add a way to upload commits directly using the bonsai format via edenapi, instead of using the hg format and converting on server.
The reason this is necessary is that snapshots will be uploaded on bonsai format directly, as hg format doesn't support them. So this is a stepping stone to do that, first being implemented on commit cloud upload, as that code already uses eden api, and later will be used by the snapshotting commands.
## This diff
Modifies `uploadfileblobs_py` API method so that it returns the indexed UploadToken's. This will be used on the client code to get the content ids from the upload files, which are necessary to specify when storing the commit in Bonsai format. This is calculated in Rust when uploading the files, and we reuse the result so it doesn't need to be calculated again.
It reuses the `UploadHgFilenodeResponse` struct, which has the exact same format it needs. That is a bit ugly, and its refactored in D29878626.
Reviewed By: liubov-dmitrieva
Differential Revision: D29879617
fbshipit-source-id: 4e7bda1e1160da11c83f43002530fd1aba08d46d
Summary:
## High level goal
This stack aims to add a way to upload commits directly using the bonsai format via edenapi, instead of using the hg format and converting on server.
The reason this is necessary is that snapshots will be uploaded on bonsai format directly, as hg format doesn't support them. So this is a stepping stone to do that, first being implemented on commit cloud upload, as that code already uses eden api, and later will be used by the snapshotting commands.
## This diff
This diff adds the new endpoint to the API that can be acessed via python code, and in turn calls the api implemented on the last diff.
Reviewed By: liubov-dmitrieva
Differential Revision: D29849962
fbshipit-source-id: 5a2a674aef1edd3b0d95cb2b45b02ef9c20aca48
Summary:
## High level goal
This stack aims to add a way to upload commits directly using the bonsai format via edenapi, instead of using the hg format and converting on server.
The reason this is necessary is that snapshots will be uploaded on bonsai format directly, as hg format doesn't support them. So this is a stepping stone to do that, first being implemented on commit cloud upload, as that code already uses eden api, and later will be used by the snapshotting commands.
## This diff
This diff adds a trait method to call the endpoint added on D29849963.
It's mostly boilerplate, calling the correct endpoint, converting types from/to wire.
Reviewed By: liubov-dmitrieva
Differential Revision: D29849965
fbshipit-source-id: 4a821e965fe4319fddd8e13b13ed4de5b7f86e93
Summary:
## High level goal
This stack aims to add a way to upload commits directly using the bonsai format via edenapi, instead of using the hg format and converting on server.
The reason this is necessary is that snapshots will be uploaded on bonsai format directly, as hg format doesn't support them. So this is a stepping stone to do that, first being implemented on commit cloud upload, as that code already uses eden api, and later will be used by the snapshotting commands.
## This diff
This diff creates an endpoint on eden api which uploads a commit using the bonsai format.
It also adds all the necessary types to represent a bonsai commit (basically the same as hg commit, but no manifests, and a bit more detail on how each file changed) via the wire, and related boilerplate.
Reviewed By: liubov-dmitrieva
Differential Revision: D29849963
fbshipit-source-id: 2ff44d53874449ae4373a0135a60ead40c541309
Summary:
## High level goal
This stack aims to add a way to upload commits directly using the bonsai format via edenapi, instead of using the hg format and converting on server.
The reason this is necessary is that snapshots will be uploaded on bonsai format directly, as hg format doesn't support them. So this is a stepping stone to do that, first being implemented on commit cloud upload, as that code already uses eden api, and later will be used by the snapshotting commands.
## This diff
Uploads file contents without uploading filenodes. Will be used for uploading a
commit in bonsair format instead of mercurial format via EdenAPI.
This is basically the same method as before D29549091 (d327996144).
Reviewed By: liubov-dmitrieva
Differential Revision: D29799484
fbshipit-source-id: 136c058ebcd814f39c5b903f5d8bfef7ff6005dc
Summary: It makes it easier to understand what went wrong
Reviewed By: krallin
Differential Revision: D29894836
fbshipit-source-id: 1bc759067350b823d388fcab9a8cee41da4423af
Summary:
If for some reason EdenFS cannot be started, we shouldn't attempt to run the
fsck tests as these would always fail.
Reviewed By: genevievehelsel
Differential Revision: D29918436
fbshipit-source-id: 6e4a01a747157427e5c1028084e32cef8066c96a
Summary: This affects all platforms but more noticeable on Mac that tons of 100% printed (e.g. P409794954), probably due to some weirdness with cursor.
Reviewed By: fanzeyi
Differential Revision: D29922276
fbshipit-source-id: 987f6b9ef5a8a4ab738aa6edbd617184bbcb2d1c
