Summary:
Up to now, this has been done in chef, and thus for repos that we do not list,
they may share the memcache keys, with potential unintended consequences. Let's
always add the repo name to the key, so we can simplify the code in chef.
One small negative effect of this change is that while it is being rolled out,
the cache hit rate will be impacted. This should resolve itself quickly.
Reviewed By: DurhamG
Differential Revision: D19885775
fbshipit-source-id: 0b59ce9e378b0ab70f696a39d19d27cd89921098
Summary:
When using the `--date` parameter to `hg update` or `hg revert`,
`cmdutil.finddate` returns the binary node for the target commit. Passing this
to `scmutil.revsingle` sometimes works, however it's unreliable, as if the
binary node happens to look vaguely like a revset, we will attempt to parse it,
and perhaps fail.
Resolve the ambiguity by converting the binary node to hex.
Reviewed By: quark-zju
Differential Revision: D19902595
fbshipit-source-id: 5eb7b9b029e292a02ccc00f5a465ab7807cd56d5
Summary:
Failing means that we fallback to the Python importer. Let's simply warn about
it.
Reviewed By: fanzeyi
Differential Revision: D19897274
fbshipit-source-id: f9c63f5aa76015c28b31f00bba98244f5c86e923
Summary:
Some Mononoke tests test about the backtrace. Having the environment variables
set break those tests. Clear them.
Reviewed By: xavierd
Differential Revision: D19887219
fbshipit-source-id: 529a17282c40730ee95bffbed00070edd1f0823a
Summary:
`mt.exe` can fail when Windows Anti-Virus scans the same file. Retry on such
failures. This hopefully can improve our build success rate on the Windows
platform.
Reviewed By: xavierd
Differential Revision: D19887220
fbshipit-source-id: b725d5fe883bd52697b58b74dbb4a338c02c3ed6
Summary:
This is an attempt to fix the following error:
```
--- test-fb-hgext-treemanifest-server.t
+++ test-fb-hgext-treemanifest-server.t.simplecachestore.err
@@ -167,8 +167,9 @@
$ hg push --to mybook
pushing to ssh://user@dummy/master
searching for changes
- remote: prepushrebase.myhook hook exited with status 1
+ remote: prepushrebase.myhook hook exited with status 2
abort: push failed on remote
+ remote: $TESTTMP/myhook.sh: 2: $TESTTMP/myhook.sh: [[: not found
[255]
```
which I suspect is caused by a non-bash default shell.
Reviewed By: xavierd
Differential Revision: D19887222
fbshipit-source-id: b6fe5d89e4c41ff49fca86da927c4e702ed1e7c1
Summary:
This is needed by the next diff. Otherwise Python 3 ssh tests in the next diff
will hang.
Reviewed By: DurhamG
Differential Revision: D19879882
fbshipit-source-id: ecc317d0685993c6b1bef8c72068bf4315030d0f
Summary:
I'm going to change the connection pool logic but I'm not sure where it gets
used. This change exposes at least one test using it.
Reviewed By: xavierd
Differential Revision: D19872614
fbshipit-source-id: 4921b92c3fe3fd7ba1a72de17eef92604964eb2e
Summary:
Regressed since D19702533. This test breakage is only visible if
lfs-test-server exists.
Reviewed By: farnz
Differential Revision: D19872608
fbshipit-source-id: 74ace3eb7363bb1bb773e6b448685e9a3874086f
Summary: The script does not run with the stock python since it depends on edenscm.
Reviewed By: farnz
Differential Revision: D19872953
fbshipit-source-id: 4c5b2d2935a0c9e8cf0a654f541600d7a4fd7211
Summary:
Right now, if the client establishes connection to more than one peer, the
last one to proces `clienttelemetry` wireproto command gets the honor to set
`server_realhostname`. This is not desirable. Specifically, when we have
`fallbackpath` set up for remotefilelog/treemanifest and the prefetch happens
after pulling a commit, we get the hostname of the fallbackpath server,
while losing the hostname of the original `getbundle` server.
Reviewed By: DurhamG
Differential Revision: D19837570
fbshipit-source-id: fdc41565a5dfe670df3caf3b034196c4b7bdf6d9
Summary: It is helpful in CI to be able to remove all eden managed volumes at the end of a job, so that is what this command does.
Reviewed By: simpkins
Differential Revision: D19794482
fbshipit-source-id: d832d093d0a6369a4b533d66afbdce626fa78e2c
Summary:
In the initial iteration of eden_apfs_mount_helper I parsed the human
readable version of the `diskutil apfs list` output to get all of the useful
information from it. Later, I switched to using `diskutil apfs list -plist`
because it simplified the parsing dramatically.
However, it was overlooked that the `mount_point` field was not present in
the plist output. That was usually fine, except in the one case that I
didn't test after changing the parser: after reboot macOS picks a volume
name to remount these volumes. The lack of the mount_point field meant
that we would simply skip the logic that deals with unmounting and remounting
the volume in the correct place.
In order to address this gap we now need to parse the mount table to determine
where the device is mounted, so that is what this diff does.
Reviewed By: simpkins
Differential Revision: D19794478
fbshipit-source-id: ace2df145a46aad7df78c3f4b15fb2198aef3e6f
Summary:
This is done on a sort of best effort basis; the problem
we're aiming to solve (or at least avoid in the majority of cases)
is in these scenarios:
* `buck clean` gives up cleaning as soon as it finds a directory that
it doesn't have permissions to remove.
* `yarn` tries to look for node modules inside the `.Trashes` dir,
which it doesn't have permissions to access
macOS doesn't give us a solid way to indicate that these things should
be disabled at the time that we mount the volume; the various docs
and suggestions online all involve creating marker files to block the
system processes from performing their usual actions, and we could
set those up here, but if we create them with root permissions we'll
trigger the bad behavior in buck and yarn. If we create them with
regular user permissions then eg: running buck clean would remove them
and allow the system to recreate them.
The system will recreate the `.Trashes` directory when the user sends
something to the trash via Finder. Similarly, macOS will recreate
the fsevents directories when an application establishes a watch
on the volume using fsevents.
So we can't permanently prevent this problem, but by deleting these
things at mount time we should at least avoid it bubbling up for
the majority of users, and if those things come back and get in the
way, running `eden redirect unmount ; eden redirect fixup` should
remount and re-remove the problematic things.
Reviewed By: fanzeyi
Differential Revision: D19841514
fbshipit-source-id: f530ab3d68edfa643096bd27efae71c80b505184
Summary:
This makes it possible to use `Bytes` for mmap buffers.
The changes are because `minibytes::Bytes` does not implement `From<&[u8]>`
with the intention to make slice copy explicit.
Reviewed By: xavierd
Differential Revision: D19818719
fbshipit-source-id: c34ee451bfd2dc7bcbbcebd52a76444b6c236849
Summary:
EdenFS will now be able to fetch blobs directly from memcache. This won't have
any big benefits as no blobs are in memcache right now, but over time, this
will significantly reduce the cost of fetching blobs.
Reviewed By: fanzeyi
Differential Revision: D19861643
fbshipit-source-id: c2e9d317bd30d4656bf0b3f8897794161697761a
Summary:
These tracing points will help us understand the memcache hit rate as well as
the fetching speed.
Reviewed By: quark-zju
Differential Revision: D19836499
fbshipit-source-id: 1936c44efc3e7715069e6a959f5331139d591d5c
Summary:
Everytime a cache miss is seen, the data fetched from the server will be sent
directly to memcache for future use. Unfortunately, doing so in a blocking
manner severely impact the overall fetching speed from the server. Since
memcache is purely an optimization, we can afford to send data to it
asynchronously.
Let's move as much as possible of the code to a background thread to reduce the
overhead of memcache.
Reviewed By: DurhamG
Differential Revision: D19836011
fbshipit-source-id: 68e506ef7464d6e99d98457d0d37178f514be1a9
Summary:
Instead of fetching data one-by-one, let's prefetch data concurrently by using
the new get_iter function.
Reviewed By: DurhamG
Differential Revision: D19836009
fbshipit-source-id: 4a50328c0cbbba677c2de3777ebe4c34cb10c1e2
Summary: Test that mercurial can accept a unicode commit message.
Reviewed By: xavierd
Differential Revision: D19838221
fbshipit-source-id: b6333e587004b358a3883db70e40d2f32af4da29
Summary:
Even when memcache would be able to prefetch everything, this would always call
into the underlying remote store with an empt key set. For things like `hg
prefetch` and a large number of keys, the effect of doing that is minimum, but
for EdenFS or `hg log -p`, the roundtrip to the server for every file/revision
would add a significant amount of overhead. Let's simply stop iterating when we
no longer need to fetch anything.
Reviewed By: DurhamG
Differential Revision: D19835797
fbshipit-source-id: 54ad704428c3b20d973cfa87f7171899ec44b3f9
Summary:
Don't rebuild the memcache store everytime. This avoid spawning a thread and
reconnecting to memcache everytime.
Reviewed By: DurhamG
Differential Revision: D19797911
fbshipit-source-id: 7ecfa111a98ab67c4791b91410a22e458fe169f6
Summary:
We don't use the feature in production. The main motivation is to remove the
flaky test. People wanting this feature can use normal hooks instead.
Reviewed By: xavierd
Differential Revision: D19830033
fbshipit-source-id: 0b1df7bb6c5de116ee27df4c38071912568d893e
Summary:
We never actually enabled it in production, and our new storage (ex. metalog,
indexedlog) are SIGKILL-safe. Only the changelog (revlog) might be subject to
double Ctrl+C issues. And we have debugfixcorrupt which can fix changelog
corruptions. So nointerrupt becomes less important.
The direct motivation is the test has been too flaky recently (and it's hard to
reproduce locally).
Differential Revision: D19830032
fbshipit-source-id: 87722d730fab49efbfd231772b1a5dddf8ec0d7b
Summary: Not very useful on today's hardware.
Reviewed By: quark-zju
Differential Revision: D19783741
fbshipit-source-id: d8ff29486cdc5f8e31d929d9fbba827e37012381
Summary:
We don't have confidence that python 2 is only using bytes (vs unicode
or other byte-like objects). These asserts break users, so let's disable them
except for in tests. We should uncover issues here as we port to python 3.
Reviewed By: xavierd
Differential Revision: D19819699
fbshipit-source-id: 9e3a9c34e7661fac4db9ee2a79f65be3d5e48cb3
Summary:
As part of the py3 migration we've started enforcing that encodeutf8 is
only called on bytes. graphql is returning unicode, so we need to change it to
return bytes on python 2.
Reviewed By: xavierd
Differential Revision: D19819701
fbshipit-source-id: 433ced2da87d522e4234ff453d11cacfaeebdd8d
Summary:
ui.log apparently receives non-utf8 data occasionally, which makes the
encoding fail. Let's change this to not encode on python2 (by using pycompat).
As we migrate to python 3 all the strings should become unicode, and this will once
again enforce utf8 encoding
Reviewed By: xavierd
Differential Revision: D19819700
fbshipit-source-id: 66da26d00d1b1c4286e325f0574ad7ff478e5d1f
Summary:
This commit manually synchronizes the internal move of
fbcode/scm/mononoke under fbcode/eden/mononoke which couldn't be
performed by ShipIt automatically.
Reviewed By: StanislavGlebik
Differential Revision: D19722832
fbshipit-source-id: 52fbc8bc42a8940b39872dfb8b00ce9c0f6b0800
Summary:
Attach the content to the exception object directly so if the exception is
handled, no verbose message will be printed.
Reviewed By: DurhamG
Differential Revision: D19817404
fbshipit-source-id: 9b79952559d07eb62bd7eb2398c6dd022ffe7b28
Summary:
I think I might want to call this from more than one place in
a later diff, so extract it into a helper function.
Reviewed By: chadaustin
Differential Revision: D19770166
fbshipit-source-id: e044003736c6ba21984a9129da1df50ce92b2f35
Summary:
See also https://github.com/serde-rs/bytes/.
This will be used in the `dag` crate.
Reviewed By: DurhamG
Differential Revision: D19770858
fbshipit-source-id: 2a870a564e0ceecdc7a4667853b2b2a5ea4ce6e3
Summary:
This crate provides the core features of the commonly known `Bytes` crate:
zero-copy slicing and cloning, while also supports mmap-backed buffers.
The main motivation is to replace `Mmap` in `indexedlog`. That has multiple
benefits:
- Handles 0-sized mmap more cleanly.
- Handles clones more cleanly.
- Gain the flexibility to zero-copy data without lifetime / reference.
- Gain the flexibility to switch to non-mmap data.
The `bytes::Bytes` crate does not yet support mmap buffers as of its latest
release (0.5.4).
Implementation wise, `minibytes::Bytes` uses `Option<Arc<dyn Trait>>` for the
"trait object". This makes implementing the mmap storage just one line.
`bytes 0.5.4` re-invents the "trait object" manually using unsafe code. It requires
about 50 lines to implement the mmap storage (in D19756122).
Reviewed By: xavierd
Differential Revision: D19770856
fbshipit-source-id: 8cfa7052a18ac2e0cd6348b77d5e2a4acc61195c
Summary:
Our main data table has no information about the actual failure. Let's
upload a stack trace to blob storage and link to it from the main table.
Reviewed By: quark-zju
Differential Revision: D19780653
fbshipit-source-id: acaab29a47d32dd6ab81fed0c3ae50c8eb44b760
Summary:
If the main process forks, the connection to the cache client is likely
unusable. Let's drop that connection and we can recreate it later if needed.
Reviewed By: quark-zju
Differential Revision: D19796387
fbshipit-source-id: 59b0d3db9655d2233b55effcdf18cbd74a3f5edd
Summary:
We're seeing an error where worker processes fail to fetch data from
the server. Our theory is that the forking messes up the ssh connection, so
let's not reuse ssh connections across forks.
Reviewed By: xavierd
Differential Revision: D19794281
fbshipit-source-id: 3954cd96617fd18ecf0d0aa9b9a6ce774c494067
Summary:
In D19581174 I made `--debug` trigger ipdb session for `.t` tests.
This diff adds similar feature for `.py` tests.
Reviewed By: DurhamG
Differential Revision: D19784795
fbshipit-source-id: 9118c74ea465320f15aa6ad5e1e04d8bc1a49966
Summary: fixes printing for no match found in revlog match
Reviewed By: quark-zju
Differential Revision: D19652374
fbshipit-source-id: 55bfcbff7919ad817173241e2792df27311b931e
Summary:
Print out the name of the commit and the stack.
Hopefully this can help making debugging KeyErrors easier.
Reviewed By: DurhamG
Differential Revision: D19776181
fbshipit-source-id: 2eb985dd5355732a4d7728af68eb16173c48caa5
Summary: This makes the output more readable even if the "name" of a span is very long.
Reviewed By: DurhamG
Differential Revision: D19780536
fbshipit-source-id: dce0d3777409c32b0752db51341a572addb823ea
Summary:
The use of json meant the progress step was coming out as unicode when
it should be str. Use the mercurial.json functions to solve this for python 2
and 3.
Reviewed By: xavierd
Differential Revision: D19777255
fbshipit-source-id: 15c8e45425fc8742b6e118249104fc1fb2f3345d
Summary:
Now that the source of truth for third-party crates is in fbsource, let's use
it in our cargo build system. This removes the need to fetch a tarball and
untar it, which should have the benefit of speeding up the build.
A small caveat is the first build on EdenFS will be slightly slower, due to
crates needing to be individually fetched, subsequent builds will be faster.
Reviewed By: jsgf
Differential Revision: D19726217
fbshipit-source-id: 24f484d1e3118a76e052f07ff3eea0c66cccce96
Summary:
As initializing the memcache client takes ~0.7s, let's move it to a background
thread as to not impact Mercurial startup time. This diff uses ArcSwap in
order to reduce the overhead of the very common read paths as much as possible.
Using Mutex or RwLock instead would have caused unecessary contention.
Reviewed By: DurhamG
Differential Revision: D19518693
fbshipit-source-id: 886e9b86813fda6ff005ccce99659890026f643a
Summary:
This allows the Python code to build a memcache client and build ContentStore
and MetadataStore with it.
Reviewed By: DurhamG
Differential Revision: D19518694
fbshipit-source-id: d932fd5223ccfdf37db69cbb54a11a6571312709
Summary:
This enables an in-process memcache client for the Rust
ContentStore/MetadataStore. For now, this implementation is lacking several
necessary optimization:
- Start-up time is always slowed down by ~0.7s, the initialization will be
moved to a background thread
- Writing data to memcache is blocking and will be moved to a background
thread too.
- Prefetching data does a roundtrip to memcache for every key, batching
memcache APIs will be added.
Compared to the existing hg_memcache_client, this implementation is both
significantly shorter and do not exhibit some of the pathological behavior of
having to flush the indexedlog for every fetched blob when used in Eden.
Reviewed By: DurhamG
Differential Revision: D19518696
fbshipit-source-id: 4725447d13e7eddd9586135c2511e13ddb921771
