Summary:
Remove a bit of boilerplate in the definition of subcommands, and pave
the way for sub-sub commands.
Reviewed By: xavierd
Differential Revision: D26416574
fbshipit-source-id: 1477505cab6c3de2c7ac14fe862d366a707d155b
Summary: This should fix issues where master points to an unknown commit somehow.
Reviewed By: DurhamG
Differential Revision: D26648623
fbshipit-source-id: 63f7a4b834bf19a7849a1c3771921e6b1e5919d3
Summary:
This diff allows the user to specify a merge function in the shape of `merge(&mut T, T);` to customizing merging behavior.
This is used in the next diff to merge the `HashMap` that catches all unknown fields.
Reviewed By: xavierd
Differential Revision: D26415382
fbshipit-source-id: 10801ddc7d41b82d8d165a8b63466aa9b92baaab
Summary: With this diff we can start to handle concrete error types, return correct exit code for Thrift IO errors for example.
Reviewed By: xavierd
Differential Revision: D26412948
fbshipit-source-id: f598ed2d9187126509c149f9d6293025d0f39968
Summary:
hg status was throwing an error on Py3 OSX because a fallback path
returned bytes instead of string. This fixes that.
Reviewed By: sfilipco, singhsrb
Differential Revision: D26702166
fbshipit-source-id: fa32e5b312377a899b6af16f40bca051f44ed6c3
Summary:
Xavier reported seeing a pile of redundant checkout events in his
journal, which caused Watchman to issue a series of no-op, sequential hg
status calls, which caused Buck to time out waiting for Watchman.
We're not sure what paths cause Mercurial to issue no-op
checkOutRevision Thrift calls, but we can certainly filter them out
inside of the journal.
Reviewed By: fanzeyi
Differential Revision: D26699828
fbshipit-source-id: f738b53bbafa4027dd70322d64413246bb5bb828
Summary: This simply adds the types to implement the CREATE RPC call.
Reviewed By: kmancini
Differential Revision: D26654767
fbshipit-source-id: 5972102aebb3b06c6838a28f3a191304efc7c945
Summary:
The MKDIR RPC is the first RPC that modifies the working copy. It is only
partially implemented due to the parent directory attributes not being
collected just yet. Implementing these will be essential for good caching on
the client side. For simplicity reason, this isn't done just yet.
Reviewed By: kmancini
Differential Revision: D26644056
fbshipit-source-id: f99add63a2ce5789a9aa81cefe4d04c2f4a741ed
Summary: This adds all the types necessaryt to implement the MKDIR RPC.
Reviewed By: kmancini
Differential Revision: D26644057
fbshipit-source-id: cfbcf3f0a7212433eba67f2266d5f7bcc2906a88
Summary:
This is a fairly common pattern in the NFS code, and we can reduce code
duplication by automatically implementing the XdrTrait.
Reviewed By: kmancini
Differential Revision: D26639683
fbshipit-source-id: 6e9cb14ce1538834224017b8ef88955e563d6723
Summary: There are no correct uses of the catch-all overload of `folly::exceptionStr`. Every use is a bug of some kind, leading to the impression that this overload ought to be removed.
Differential Revision: D26539622
fbshipit-source-id: dc2ca0781ea02f1327a334bb1fe2e533fa46d1b3
Summary:
If multiple requests to fetch a tree come in at the same time fast enough (where the first request hasn't had the chance to retrieve the data from Mercurial and save it in the cache), we will request to download the tree multiple times. If the tree is not in the hgcache, this means we will make an extra round trip to the server. There is no limit to how many concurrent requests can be made, meaning we could make a large amount of round trips to the server for the same tree.
This adds a tracking mechanism in which we track in progress tree fetches, and if we get a request that is already in the queue or being processed, we just return a future that will be fulfilled by the first request, instead of placing this duplicate request in the queue as well.
This also makes sure if we get a duplicate request, but the duplicate request has a higher priority than the request already in the queue, we will update the priority of the request in the queue.
Reviewed By: chadaustin
Differential Revision: D26355499
fbshipit-source-id: 8d3192cf0f5628c650715f4597c92fc8c9238650
Summary: We have a number of sleeps in our integration tests. The two main reasons are configs & tunables that need reloading. Currently, we have no way of force-reloading those.
Reviewed By: krallin
Differential Revision: D26615732
fbshipit-source-id: 217c4ae039abd398972b4a9764d08e18d6182493
Summary:
This dag periodically reloads the dag from storage.
It currently loads a simple dag that has no update logic because that is what
the manager returs. It's not relevant for this code.
This is probably the last piece before we refactor construction to take a
SegmentedChangelogConfig. To be seen how much will be strict types and how much
will be Arc<dyn SegmentedChangelog>.
Reviewed By: krallin
Differential Revision: D26681458
fbshipit-source-id: 6056d00db6f25616e8158278702f9f4120b92121
Summary: There were no unit test for SegmentedChangelogManager so I added one.
Reviewed By: krallin
Differential Revision: D26681459
fbshipit-source-id: 40ceefe7b89043ae6d2c4d31a2adf504245161fb
Summary:
A placeholder for convenience functions.
Right not it has a proxy for the head of the dag.
Reviewed By: krallin
Differential Revision: D26681457
fbshipit-source-id: 6856abbf2685407f96701ea5a508342373503360
Summary:
This is a long standing bug whereby if you made the terminal too thin,
the formatting code would crash.
This fix just prevents underflow in the precision format string (and
alignment).
Reviewed By: fanzeyi
Differential Revision: D26673865
fbshipit-source-id: 945e6f227c19962ac0926e117600aa9d6a990305
Summary:
I accidentally broke this in D26544410 (097e4ad00c) when I updated it to use
schedule_stats_aggregation_preview (in Tokio 0.2 and up, you can't create
an interval stream off the runtime, but in Tokio 0.1 you could).
We only use this method in 2 places, so it probably makes sense to just get rid
of it anyway, which is what this diff does. The alternative is better as it
spawns this unconditionally, so if we get it wrong, it'll fail in tests,
even though our tests don't pass `--fb303-port`, whereas
`start_fb303_and_stats_agg` will only start stats aggregation if its passed.
Reviewed By: ahornby
Differential Revision: D26690223
fbshipit-source-id: 7d151a3c46fa428f00ac32601da161609fb498f7
Summary:
The NFS RPC description is filled with variant over nfsstat3 with only 2 cases:
NFS3_OK, and the default one. I was feeling bad having to write the same code
again and again for the deserialize part of the XdrTrait, and thus came up with
a template solution that enables us to remove all of the boilerplate code.
The only drawback is that this moves the variant one additional layer down, and
that means an extra layer of brace when initializing it. From what I know,
this is caused by the -Wmissing-braces warning, maybe we could remove that
warning?
Reviewed By: kmancini
Differential Revision: D26627163
fbshipit-source-id: ab56dee42273f180b2edf4f529221a15154ac2fb
Summary: This seems to have been reverted by accident in D26618363 (f317302b0f).
Differential Revision: D26689734
fbshipit-source-id: e86451716cab3cc62f517c3f5fca7898d1a25095
Summary:
"value not present in store" is an unhelpful error message once
serialized through Thrift etc. Provide more useful context when a key
is missing.
Reviewed By: fanzeyi
Differential Revision: D26678102
fbshipit-source-id: 514ac2fe580d1dd7c67fc20c89b75e5d8121c329
Summary:
We got a report about windows in vscode being significantly slower than on
macOs/Linux (https://fburl.com/nv9xwc09) to the point that it can't be
explained by "Windows is just slower". As the post suggests we had a suspicion
it might be related to an issue described in T33479254.
After some debugging I can confirm the following:
1) I can reliably (but not 100% of the time) reproduce the issue on my windows
laptop. I just need to modify a file and do "Quick commit" or "Quick amend" from vscode,
and note that command finished quite fast (just a few seconds, I verified it by
running "hg st" and checking that working copy is now clean, and by running "hg
log -r ." and checking that hash has changed), but vscode takes longer to
notice that (i.e. it keeps spinning and showing that amend is still running).
2) By staring at "Process explorer" I noticed that the problem seem to be in
"hg.exe cloud backup" i.e. when "cloud backup" finishes then vscode stops
spinning. So I suspected it to be a problem.
3) As the next step I started to suspend the process in "Process Explorer"
(note that I started it as admin and SYSTEM user, whatever it means). Then I
looked through file handles in Process explorer and was closing them 1 by 1.
Evetually I noticed that closing handles for named pipes like
"\Device\NamedPipe\uv\0000013E91115170-26220" make vscode stop spinning (it was
usually necessary to close it in hg.exe cloud backup process and all child processes as
well).
4) I also looked at handle value, and noticed that it's bigger than 2048 (0x848).
So currently my suspicion is that the problem is that we don't close enought
handles, and this diff bumps it as a temporary workaround and also walk over handles that multiple of 4 only. quark-zju has an
upstream improvement that would make this hack go away
(https://github.com/rust-lang/rust/pull/75551/commits) but it's not landed yet.
So for now let's try to bump the magic number.
Reviewed By: quark-zju
Differential Revision: D26668773
fbshipit-source-id: ed1c203260a52c3e5449b7b06cf4ecbe4dcf6477
Summary:
Previously, when an argument was just a plan filehandle, I just bypassed adding
the structure and just read the handle directly from the stream. kmancini
correctly pointed out that this is a bit confusing, thus let's add the arg
struct everywhere to cut that confusion.
Reviewed By: kmancini
Differential Revision: D26649568
fbshipit-source-id: bc4d6e519450f228d151a3de7acdfc1002c43b38
Summary:
This is merely a forward to the readlink FileInode method. This allows the
.eden directory and its symlinks to be read properly.
Reviewed By: kmancini
Differential Revision: D26619947
fbshipit-source-id: d5f8ef81ce3000c0f0a2f47007affe2c0292ef31
Summary: This adds the various types necessary to implement the READLINK RPC.
Reviewed By: kmancini
Differential Revision: D26610437
fbshipit-source-id: a64644d0499381678170da38886b5dff1c1b9270
Summary:
The LOOKUP RPC is a bit tricky as we need to special case the "." and ".."
names to represent the current and parent directories. Obtaining the parent
directory is inherently racy from the client perspective, and thus EdenFS won't
try to hold the renameLock in this case.
Reviewed By: kmancini
Differential Revision: D26597789
fbshipit-source-id: 9c8dcaf7db84f8c09f7505cab7afed48df79b754
Summary:
See D26671795. The hotfix was ineffective because repo config (and
dynamicconfig) is not loaded. This fix ensures newer versions of
hg do not depend on the hotifx.
Reviewed By: DurhamG
Differential Revision: D26679775
fbshipit-source-id: 5e78051cb7d9ac9ac6b327d895049dca2b025068
Summary:
An OnDemandUpdateDag can now track a bookmark. Every given period it will
query the changeset of the bookmark and incrementally build the dag.
Reviewed By: krallin
Differential Revision: D26656765
fbshipit-source-id: 95057863b5201f9632c654be5544922c7538f974
Summary:
For dependencies V2 puts "version" as the first attribute of dependency or just after "package" if present.
Workspace section is after patch section in V2 and since V2 autoformats patch section then the third-party/rust/Cargo.toml manual entries had to be formatted manually since V1 takes it as it is.
The thrift files are to have "generated by autocargo" and not only "generated" on their first line. This diff also removes some previously generated thrift files that have been incorrectly left when the corresponding Cargo.toml was removed.
Reviewed By: ikostia
Differential Revision: D26618363
fbshipit-source-id: c45d296074f5b0319bba975f3cb0240119729c92
Summary: Can save some allocations and copies by mapping the binary type to bytes::Bytes
Reviewed By: krallin
Differential Revision: D26575835
fbshipit-source-id: 518d2505e89e683d771494b53cb5fae5aea2110b
Summary:
Migrate away from streaming Thrift Python, and instead implement `eden
trace hg` in C++, which will eventually let us support Windows.
This also fixes an unexplained crash in `eden trace hg` on macOS.
Reviewed By: xavierd
Differential Revision: D25515377
fbshipit-source-id: 1916aa7f09df37e9dee3479a858932c724f8aed4
Summary:
We use an EWMA of lag values to ensure that we don't alternate between full speed writes and waiting, but instead give the DB a chance to catch up on replication after writes.
However, in S223394, we saw MyAdmin return extremely high lag values. Because our EWMA is uncapped, and we decay by half each interval, a false spike of 500 seconds takes log2(500 / 5) = 7 seconds to decay back down to the point where we will write our next chunk, assuming that lag is 0 after the false spike (not true, so can be more seconds before lag falls)
Resolve this by capping the EWMA calculation, so that we recover quickly from a false spike (max of 2 seconds with current limit), while still blocking writes while MySQL replication catches up if lag stays high.
Reviewed By: mitrandir77
Differential Revision: D26663528
fbshipit-source-id: 6e5c06f79f08ac6ebbca1b3076816a15ab8353e5
Summary: When building against Python 3.8 the MSVC compiler complains about how this macro splits inside parentheses. Not sure what changed, but looks easy enough to fix.
Reviewed By: quark-zju
Differential Revision: D26434060
fbshipit-source-id: b46059a6e676a52c99f8923b6739cffe578cc6f7
Summary: Supports Windows by adding mkscratch and scmdaemon and updating it to build python3libs.zip instead of python27.zip. Changed the name to include 'libs' on the end since the zip no longer contains Python itself.
Reviewed By: quark-zju
Differential Revision: D26381051
fbshipit-source-id: 0a2cc40df103525fdc581a4102458e82fda1f670
Summary:
In Python 3 the strings are no longer bytes, so we need to convert them before calling Windows native APIs.
I originally attempted to make all C APIs use the W() Windows APIs. This sorta worked and enabled some unicode support for Windows in Python 2, like hg status, but it meant that utf-8 path encodings were being returned and eventually passed to python functions like os.lstat() which weren't expecting utf8 encoding. I gave up and just left the Python 2 C code as is, and made a copy that uses W() APIs for Python 3. This enables unicode support on Windows where it didn't work before (at least in my testing).
Reviewed By: quark-zju
Differential Revision: D26381053
fbshipit-source-id: 69d4e18ba9fb0f3d17bad58fbcc5d0e6e61d4252
Summary:
Windows tests were failing to execute hg clone ssh://user@dummy/... lines because setconfig ui.ssh=C:/foo/bar was being translated to ui.ssh=c;c:\\foo\\bar by mingw, since it detected /foo/bar as a unix-style path. This seems to be caused by this one line reversing the slashes. I'm not sure why it exists, but deleting it makes the tests pass.
My guess is this has been broken for about a year.
Reviewed By: quark-zju
Differential Revision: D26639206
fbshipit-source-id: d89cae1ea3dd055b90ec6ee8f7cdbee2ae08b228
Summary: This diff sets up the ability for us to track requests as they are shuffled around in the `std::vector<> queue`. Since the queue is a vector, and since it is sorted everytime a new element is added or removed, we cannot keep track of elements in the queue with indices or references. Instead, we will store the requests in a shared_ptr so we can maintain a pointer to the request no matter where the request is moved around to.
Reviewed By: kmancini
Differential Revision: D26355907
fbshipit-source-id: d714d689963106a4f495221dbcfcbab758ffc7b2
Summary: The first byte is the flag.
Reviewed By: sfilipco
Differential Revision: D26654640
fbshipit-source-id: 4d66f14c73fe40a154ca7c08f9a9dff3a54ae337
Summary:
Like our other "tokio ecosystem" crates, I'm renaming this one tokio-util-02
(as in tokio-02) since this is the last version it is compatible with. Note that this had a
breaking change as well, so I updated the callsites.
Reviewed By: HarveyHunt
Differential Revision: D26636350
fbshipit-source-id: 30f7da1036c861a97717c8d26648daaae33ecfbd
Summary:
We use a forked version of Gotham in Mononoke. This isn't great, because we
have to maintain this fork. Ideally, we'd upstream our changes, but as is
they're a bit intrusive and not generally useful, which makes this hard.
I've reworked how we do our Gotham changes, and now we only need to make 1 bit
of code public, which might be easier to get upstream. Concretely, Gotham has a
concept of "connected handler" that links a Hyper request and a socket address,
but in our case we want more things. This change lets us instantiate our own
Gotham state, and then add a few more things to it as necessary.
This diff updates our code accordingly to be compatible. This also lets us trim
down on some ceremony we had to do call into Gotham
from Mononoke Server.
Reviewed By: farnz
Differential Revision: D26634653
fbshipit-source-id: 024a48ebc3f323c165ac412ef422755e8cb1c650
Summary:
When in readonly mode we can't write anything, therefore there is no need to monitor for write delay.
Also imported nonzero_ext::nonzero! macro as a small tidy up.
Reviewed By: farnz
Differential Revision: D26662396
fbshipit-source-id: 36cb2c1375a8fb72e3976290907d4c8c34ea0f4e