Summary:
UDS don't have port numbers, so trying to register their port with the
portmapper is going to fail. This can cause eden to fail to start when we
enable uds. The current portmapper version we use can't support
this, so let's just skip attempting to register uds servers with the
portmapper.
Reviewed By: xavierd
Differential Revision: D45196379
fbshipit-source-id: 584e6e04129d1ddbcc756ed66c55a03c3955705a
Summary:
Use `FileStack.remapRevs` to calculate the file contents after reordering.
It is a bit tricky since there are various of mappings.
Reviewed By: evangrayk
Differential Revision: D45073071
fbshipit-source-id: 8b8a7e14b15d2ff2a1bbf706764be23b9ae968d7
Summary: This seems handy to use without depending on lodash. Code written by ChatGPT 4.
Reviewed By: zzl0
Differential Revision: D45073069
fbshipit-source-id: 9bb4a73d476d14310003dcce78df2515d4ff614c
Summary:
Previously, the file content in commit stack is a string, or a base85 string.
This diff extends it to support a 3rd type: lazily defined by (file stack
index, file stack rev). So if we only edit things without showing the file
contents, it might do less work under the hood.
Reviewed By: muirdm
Differential Revision: D45073072
fbshipit-source-id: 1eb351c03a464c7cf3f55af656167dab115f421a
Summary: This is useful in the upcoming changes.
Reviewed By: zzl0
Differential Revision: D45073070
fbshipit-source-id: 248ad013e3737e207c475ba05043bc2a3abfceb8
Summary: Add a way to fold down commits. The tricky parts are about rename handling.
Reviewed By: evangrayk
Differential Revision: D44856154
fbshipit-source-id: 49627f779a554f63c133494867dcbf6dc6e4ecbb
Summary: This will be useful to figure out what commit reorders are meaningful.
Reviewed By: evangrayk
Differential Revision: D44845635
fbshipit-source-id: a6b78bea89fa1a6f95b6439560620076d967064c
Summary: This is useful to figure out file dependencies.
Reviewed By: evangrayk
Differential Revision: D44845632
fbshipit-source-id: d5c6130a29223006224120bb1f794c64f0d7f036
Summary:
This diff adds logic to build file stacks from the commit stack so we can
reason about file changes for related files. The main complexity is around
renames/copies.
Reviewed By: evangrayk
Differential Revision: D44845634
fbshipit-source-id: e83b5c8f87fa9bccfa7c719e7b6c748d2e47fd31
Summary:
I used this to investigate some non-obvious logic run by isl tests.
`console.log` takes too much space in `yarn test` output.
I didn't set `runtimeExecutable`. This makes it possible to specify which
`node` to use using vscode remote settings that is not checked in source
control:
"debug.javascript.defaultRuntimeExecutable": {
"node": "/home/quark/bin/node",
"pwa-node": "/home/quark/bin/node"
},
This avoids issues where the system `/usr/local/bin/node` is too old to run the
test.
Reviewed By: evangrayk
Differential Revision: D44845631
fbshipit-source-id: a632360d196313a03d3852a3baca4504b3350f16
Summary:
Update `revLength` during `editText`. This makes it possible to append new
texts to construct a file stack instead of preparing all texts before hand.
Reviewed By: evangrayk
Differential Revision: D44845636
fbshipit-source-id: cc71e3552072ee8841296aee93bf917ef27726a1
Summary:
It turns out `null` forces a lot of annoying cases to handle.
Inside commit stack let's use a non-none structure to represent absent
or deleted files.
Reviewed By: evangrayk
Differential Revision: D44845637
fbshipit-source-id: 4c05420613db86aab227ca3b4cbfe177a8d774e0
Summary:
The commitStackState maintains a stack of commits and is intended to provide
read and write operations.
This diff adds basic read operations (cat, log). More complex operations
will be added later.
Right now, the implementation supports forks in the stack (but not merges or
disconnected stacks). If that adds too much undesired complexity we might want
to restrict it to linear stack later.
Reviewed By: evangrayk
Differential Revision: D44845639
fbshipit-source-id: 2a9833dd6fabe7b5c4ecd3f199a362d25f306bd3
Summary:
The stack types are meant to be JSON (de-)serialized. `Map` does not play well
with JSON so let's change them to classic object `{A: B}` format.
Reviewed By: evangrayk
Differential Revision: D44845633
fbshipit-source-id: 9f8eb539defe084f325ce9d1de2fa7159914467f
Summary:
The case that I met was like the following DAG, and I'd like to skip those `Landed` commits when running `hg ab` since they already landed.
```
╷ o zzz Apr 21 at 18:18 zhaolong
╷ │ commit zzz
╷ │
╷ o yyy Apr 21 at 17:18 zhaolong
╷ │ commit yyy
╷ │
╷ x ccc [Landed as ddd] Apr 21 at 9:00 zhaolong
╷ ╷ commit bbb
╷ ╷
╷ x aaa [Landed as bbb] Apr 12 at 08:00 zhaolong
╭─╯ commit aaa
```
Reviewed By: sggutier
Differential Revision: D45184140
fbshipit-source-id: a539468843032d41ab4d61e5c461b9a1de53cb40
Summary: Like in the previous diffs, this diff uploads the raw git tags during repo import through `gitimport`.
Differential Revision: D45118571
fbshipit-source-id: f5a6bb9b5805235e9f66f97ab3a58bd165ef475c
Summary: The previous diff uploaded raw git commit data while the commit gets imported in Mononoke through gitimport or remote-gitimport. This diff ensures that the git `tree` associated with the commit also gets uploaded in Mononoke.
Differential Revision: D45085959
fbshipit-source-id: cf4f4a5ebd0d077972f75fe9c6a8d1dfc5067180
Summary:
With the `upload_object` method in place, this diff utilizes the new uploader method to upload the raw git commit in Mononoke store before creating its corresponding Changeset at Mononoke end.
This diff has the following changes:
- Modified the `get_object` method in `GitReader` to return the raw git content (i.e. header + body bytes of git object) along with the parsed `GitObject`
- Added the `read_raw_commit` method in the `gitimport_objects` library to read the raw commit bytes
- Modified the `ExtractedCommit` type to contain the raw bytes of the commit as well
- Modified all modes of `gitimport` execution to upload the raw git commit before creating the corresponding changeset at Mononoke end
- Made changes in integration test to validate the commit upload behavior
Differential Revision: D45082135
fbshipit-source-id: f339b2851646996be7f43f02458ea5afabb9ca48
Summary:
This diff includes the following changes:
- Introduces the `upload_object` method in the `GitUploader` trait for uploading raw git-objects (e.g. commit, tree, tag) in the mercurial mirror of the repo
- Implements the `upload_object` method in `Direct` and `Remote` implementations of the `GitUploader` trait allowing the objects to uploaded from both `gitimport` and `remote-gitimport`
This diff just introduces this method, follow-up diffs will use it for uploading different commit objects.
Differential Revision: D45046811
fbshipit-source-id: 9b4e6a295ec22e06294e410735e67877e6d0ef10
Summary:
The existing `mononoke_api` git methods were defined under `RepoContext` which relies on a specific type of `Repo` facet container as defined in `mononoke_api` crate. These methods can easily be used through SCS which serves as an external entry point into the `mononoke_api` crate. `remote-gitimport` uses SCS and thus can leverage the necessary endpoints.
However, `gitimport` (or `direct-gitimport`) directly references the logic behind these methods. To ensure that we don't repeat ourselves, there are two alternatives.
- Make `gitimport` use the same `Repo` facet container as the one in `mononoke_api` crate
- Decouple the git methods from `RepoContext` and define them with explicit `facet` dependencies
I chose the later since using the same facet container would have made `gitimport` use a much bulkier `Repo` definition than is necessary. I also made some changes in the `create_annotated_tag` method which are as follows:
- Removed the `start_write()` statement which was essentially an authorization check to validate if writing to the repo is allowed. This check makes sense when validating an external caller (e.g. SCS) but direct references of the library should be allowed
- Removed `CreateChangeset` permission check since we are not actually creating a changeset that corresponds to a commit. Additionally, any auth checks need to be performed at the call-site (e.g. SCS) and not in the API
- Removed the `allowed_no_parents` check since any changeset created for representing a `Tag` object will not have a parent. Infact the concept of parent is invalid for a tag.
- Replaced the returned `MononokeError` into `GitError` to maintain consistency with other methods
- Replaced the instance `save_changeset` method with the struct-level `save_changeset` method. The new method doesn't log to the scribe category thus preventing users tailing it from receiving an invalid commit creation notification. Additionally, the new method doesn't consider any bubble changes but they are anyway irrelevant in the context of these git methods.
Differential Revision: D45046639
fbshipit-source-id: 7ff02cde3fd356eb7a18f5ca12e6c478e23ee315
Summary:
Previously, the nfs.allow-apple-double was tentatively rolled out but had to be
rolled back as XCode disliked when an AppleDouble file was present on disk but
a new one couldn't be created. To avoid this issue, let's prevent AppleDouble
from being loaded from the Overlay and re-write the Overlay for directories
that contains one at the same time.
As a slight behavior change, the nfs.allow-apple-double is no longer read on
the fly but only read at startup time to avoid cases where a TreeInode is
already loaded with an AppleDouble and the config is flipped which would cause
XCode to fail to save files.
Reviewed By: chadaustin
Differential Revision: D44854105
fbshipit-source-id: 2c263411719d19eb1d457e26661620e8d6c905ce
Summary: In preparation for deleting blame v1, make blame v2 the default.
Differential Revision: D45044338
fbshipit-source-id: c9c71a148b42f4a3301d6c4fd0de5ad7ed321a3e
Summary:
Allow the walker to walk the blame v2 graph.
Since the walker is the main user of blame in the integration tests, we can make v2 the default for the integration tests, too.
Differential Revision: D45044294
fbshipit-source-id: 52c991dd81be78053ffc0a6953caf8a068ef59e3
Summary: This is a benchmark, so put it with the other benchmarks.
Differential Revision: D45114045
fbshipit-source-id: c524c76671d4183f6baa71ca9cd4c3cdfc402dac
Summary:
We don't need folly::Synchronized for the RpcServer state
machine. It's only touched from the EventBase, so make it
EventBaseState.
Reviewed By: xavierd
Differential Revision: D44860240
fbshipit-source-id: bcbc3d02e7cc5f2dc377718065c7f95eed30202d
Summary:
There's nothing TCP-specific about RpcTcpHandler, so give it a more
accurate name.
Reviewed By: xavierd
Differential Revision: D44860198
fbshipit-source-id: 55b9dc95b2caa9d87179a17435313b91bacfee49
Summary:
RpcServer can handle the accept callbacks directly. There's no need
for an intermediate object.
Reviewed By: xavierd
Differential Revision: D44860163
fbshipit-source-id: fd2d96735810a52cd287c357534c8f5bae9eee90
Summary:
I plan to use StateWrapper elsewhere so rename it to EventBaseState
and move it to the top level.
Reviewed By: xavierd
Differential Revision: D44860040
fbshipit-source-id: fb03b3b726df50099bcce144e343be0caeeaf1be
Summary:
There is no need for an intermediate object: RpcTcpHandler can handle
the write callback methods directly.
Reviewed By: xavierd
Differential Revision: D44860027
fbshipit-source-id: fe1f44b83a371291a21a3b1b26422bef5cbbf2a0
Summary:
To simplify RpcServer further, assert that removal of the accept
callback is a synchronous operation. Previously, it wasn't, because
specifying any EventBase in addAcceptCallback created a RemoteAcceptor
which scheduled operations on the other EventBase.
Reviewed By: xavierd
Differential Revision: D44853408
fbshipit-source-id: 9369cdcb0bd8450d42e195c15738362d4a53d2e7
Summary:
I'm trying to track down a subtle lifetime rule violation in
EdenMount. While reading RpcServer, I noticed a few possible
simplifications.
Reviewed By: xavierd
Differential Revision: D44849773
fbshipit-source-id: 4c27c47a7e2c211dcd040acce955e9b2f617b55b
Summary:
This removes an ifdef _WIN32 in mount shutdown by standardizing the
takeover logic on all three platforms.
Projected FS doesn't support takeover, but removing ifdefs allows
simplifying the control flow and unblocking NFS or other FsChannel
implementations on Windows.
Reviewed By: kmancini
Differential Revision: D44737273
fbshipit-source-id: fc6b718e01698ef3700b5c198750c0e3b1f62063
Summary:
By moving NFS's StopData behind FsStopData, the std::variant and
runtime checks during takeover can be unified into one path. The next
diff will do the same for Windows.
Reviewed By: kmancini
Differential Revision: D44737160
fbshipit-source-id: 19ca623f90b367d25385f177cafa44d7bf7ebb62
Summary: To support opting out of the new ISL, we should close the new ISL when you click the opt out button. This means we need a command to close the webview. We could handle this other ways, but a command is pretty easy to do and useful. The command is not exposed in the package.json so it won't be user-visible.
Reviewed By: quark-zju
Differential Revision: D45129282
fbshipit-source-id: 9feb79701ccd48512a1ddfba89427e72e621c261
Summary: I noticed tooltips that wrapped text would cut off words midway. We used `word-break: break-all` to support long file paths, instead of the more reasonable `break-word`.
Reviewed By: quark-zju
Differential Revision: D45126388
fbshipit-source-id: d256e62bfcb692cee1231886e42607c904959d19
Summary: Previous diffs this stack set us up to have an opt-out button in vscode to go back to the old ISL. Here we change the UX slightly to have an opt out button and a one-time open old ISL button.
Reviewed By: quark-zju
Differential Revision: D45126343
fbshipit-source-id: caf4a40b0220d28d31bc07e15210fed78b151243
Summary: In the previous diff, we added the UI to render the opt out / opt in button. Here I add an API for the vscode webview to read/subscribe to a vscode config and also set the config. This lets us easily implement the opt out flow without needing a special opt out message to be sent to the platform.
Reviewed By: quark-zju
Differential Revision: D45123610
fbshipit-source-id: 5c3ab94960f81becb95c90c9cd27dda3ed8fc1a5
