Summary:
`os._exit` bypasses all clean-up logic, including `IO::drop` in `hgmain` which
cleans up the progress bars. So let's explicitly clean up the progress bars
before `os._exit`.
Reviewed By: kulshrax
Differential Revision: D27744944
fbshipit-source-id: 5cd50b283728fd4e3b559142f7f61fc6672492e9
Summary: This will make RotateLog achieve zero-copy reading more easily.
Reviewed By: kulshrax
Differential Revision: D27724331
fbshipit-source-id: 57915516dc6bd1935838bd099a60c104f0bdef3d
Summary: This makes it more flexible.
Reviewed By: kulshrax
Differential Revision: D27724332
fbshipit-source-id: 43ad670519f0617a97e0b7d38b374f497e9c01af
Summary:
This allows setting the wrapping mode. For example:
lhg log -pv
# copy paste long lines works.
lhg log -pv --config pager.wrapping-mode=unwrapped
# lines are not wrapped, ">" is shown for long lines.
lhg log -pv --config pager.wrapping-mode=word
# long lines wrapped at word level.
The default value matches "less" behavior.
Reviewed By: DurhamG
Differential Revision: D27720767
fbshipit-source-id: e29d6b13656407c0a1e63287fb96e2f8d914cfc8
Summary: This is needed to prevent situation when we try writing into file that is untracked by hg
Reviewed By: DurhamG
Differential Revision: D27667152
fbshipit-source-id: 31bb9e30bd6b58e80ba96d280ff6ca1842c8caf6
Summary: This method checks if any of files that checkout writes is not tracked in hg and exists on disk
Reviewed By: DurhamG
Differential Revision: D27667153
fbshipit-source-id: 4ad8bc08520678ea0b51008ed14fb51ca4a98f76
Summary:
Previously this query failed because it tried to convert bytes to int, and our
mysql wrapper doesn't support that.
Let's cast it instead
Reviewed By: krallin
Differential Revision: D27736863
fbshipit-source-id: 66a7cb33c0f623614f292511e18eb62e31ea582f
Summary:
`hostcaps` abstracts the logic for determining whether we have a prod or corp
environment.
Reviewed By: DurhamG
Differential Revision: D27684641
fbshipit-source-id: 50df9a60b6a613b4cb5c9aed6cad2844aae85a6f
Summary:
We want to use it in Mercurial and the directory structure was playing bad
with Mononoke's OSS build.
Reviewed By: xavierd
Differential Revision: D27684642
fbshipit-source-id: 8827645eee58fa671f9c9e1964a34c34e3a8eeb6
Summary:
MacOS does not have the device field like linux that we can use to mark edenfs
nfs mounts. But there is the `f_mntfromname` field. This field more typically
might have the path which this nfs mount is mirrored from, but it should be fine
to hyjack as the edenfs indicator field.
Reviewed By: xavierd
Differential Revision: D27717945
fbshipit-source-id: 056fb39dc3273b68d79c26487fd045f4e7f93b7b
Summary:
With fuse we report "edenfs:" as the device, let's do the same thing with nfs
so watchman can recognize edenfs nfs mounts similarly.
I think its fine to use the standard "edenfs" as the server name in the mount
call rather than the address, from looking at:
https://www.systutorials.com/docs/linux/man/8-mount.nfs/
Reviewed By: xavierd
Differential Revision: D27630764
fbshipit-source-id: 9e476c90ece90e758b98d140c6bf4067dbca3661
Summary: Currently just does XDB Blobstore, because the work to do other types and/or go via Packblob is significant.
Reviewed By: markbt
Differential Revision: D27735093
fbshipit-source-id: d3797017a2e0ff7c60525d1f4d4ee3e63b519d49
Summary: We have deprecated it in favor of argument that takes a boolean value.
Reviewed By: farnz
Differential Revision: D27709429
fbshipit-source-id: 45e9569188f2e9d017f1c5bf61f7c61bc0e5318a
Summary:
It's useful when operating with timeseries to know what range of data has been
populated. This diff adds support for this in mononoke/timeseries, by tracking
the number of buckets that fall within intervals where data was provided.
Reviewed By: mitrandir77
Differential Revision: D27734229
fbshipit-source-id: 3058a7ce4da67666e8ce8a46e34e277b69153ea4
Summary:
When building skiplists, set the session class to `Background`. This ensures
that the blobstore writes for the new skiplist have completed fully.
Reviewed By: StanislavGlebik
Differential Revision: D27735411
fbshipit-source-id: 4ba8e8b91dafbb1aa258d15b26e7d773f63b5812
Summary:
If the caller asks us for a range that extends past the end of our file, we'd
rather give them an error instead of silently returning the file.
This actually revealed one of the tests needed work :)
Note that right now we'll just end up categorizing this as 500. I'd like to
rework the errors we emit in the Filestore, but that's a somewhat bigger
undertaking so I'd like to do it separately.
Reviewed By: quark-zju
Differential Revision: D27193353
fbshipit-source-id: 922d68859401eb343cffd201057ad06e4b653aad
Summary:
The backupbookmarks part was used for infinitepush backup bookmarks, which were
deprecated. Now stop sending the part entirely unless
`commitcloud.pushbackupbookmarks` is set.
Reviewed By: StanislavGlebik
Differential Revision: D27710099
fbshipit-source-id: 1eb404f106f5a8d9df6d73e11f60f89c1fa10400
Summary:
Like it says in the title, this adds support for publishing our max open
connections to ODS. Note that this is a little more involved than I would like
for it to be, but there is no way to get direct access to this information.
This means, we need to:
- Expose how many open connections we have in flight (this is done earlier in
this stack in the Rust MySQL bindings).
- Periodically get this information out out for MySQL, put it in a timeseries.
- Get the max out of said timeseries and publish it to a counter so that it can
be fetched in ODS.
This is what this diff does. Note that I've only done this for read pools,
largely because I think they're the ones we tend to exhaust the most and I'd
like to see if there is value in exposing those counters before I use them.
We do the aggregation on a dedicated thread here. I contemplated making this a
Tokio task, but I figured making it a thread would make it easier to see if
it's misbehaving in any way (also: note that the SQL client allocates a bunch
of threads already anyway).
Reviewed By: HarveyHunt
Differential Revision: D27678955
fbshipit-source-id: c7b386f3a182bae787d77e997d108d8a74a6402b
Summary: This name is more reasonable, since this commit is not actually ephemeral
Reviewed By: quark-zju
Differential Revision: D27722921
fbshipit-source-id: e2c0243d41a73341f9d0afdc79696ea37b34b8c7
Summary: Running these with tsan appears to run properly, let's try to re-enable them.
Reviewed By: genevievehelsel
Differential Revision: D27723525
fbshipit-source-id: 42e61d26cf478cbe808698a6a0615015832180fa
Summary:
We have `experimental.findcommonheadsnew` set to True in all tests, and
Rust commit backends force the `findcommonheadsnew` paths, which is
pretty much everywhere except hgsql repos. Remove `_findcommonheadsold`.
The fast discovery is also unnecessary. Remove them too.
Reviewed By: DurhamG
Differential Revision: D27630496
fbshipit-source-id: ab1948f03a8c84e75e3b5c9ff4769e17533447d2
Summary: Many users have asked what scratch directory is when they look to free some disk space. Placing a README.txt under the scratch root could be helpful to explain what is in there.
Reviewed By: fanzeyi
Differential Revision: D27710277
fbshipit-source-id: e3ccd92fa1920ac4c791026b8d98aa05a1c8b268
Summary: This diff uses filescmstore for native checkout when nativecheckout.usescmstore config is set
Reviewed By: DurhamG
Differential Revision: D27658844
fbshipit-source-id: ec3442d677ccb25e8b08cc194e4c8c18c0e01fa1
Summary:
This diff introduces CheckoutPlan::apply_read_store to apply checkout plan using ReadStore as a data source
This requires some minor changes in apply_stream flow as ReadStore does not guarantee ordering of returned files
Reviewed By: DurhamG
Differential Revision: D27658346
fbshipit-source-id: 5a289554d8dd7b6bb4b5a996659cd0661779ad5f
Summary: The latter is more lightweight.
Reviewed By: DurhamG
Differential Revision: D27641665
fbshipit-source-id: d46f62f9067eb9cb4c8517a62efa6f663d4b6732
Summary: The latter is more lightweight.
Reviewed By: DurhamG
Differential Revision: D27641669
fbshipit-source-id: d907407f5a6e868862fe37f1f67fbe99ee378156
Summary: The latter is more lightweight.
Reviewed By: DurhamG
Differential Revision: D27641667
fbshipit-source-id: adce5a39fcb5d8e8d5d989fed46991e20ab3710d
Summary: Provides a way to read config with lighter dependencies.
Reviewed By: DurhamG
Differential Revision: D27641668
fbshipit-source-id: fc99a78f5f51e63f61d1b049af74f61f5d1916a3
Summary:
The `configparser` is now too heavyweight. Some other crates (ex. io, auth,
revisionstore) just want to extract config values without complicated parsing /
remote hotfix logic.
Add a configmodel crate to satisfy the need.
Reviewed By: DurhamG
Differential Revision: D27641666
fbshipit-source-id: 26bd0b606ae3d286b3ec218927aef726d6802c63
Summary:
The CMake documentation states:
>By default, the value index of value-parameterized tests is replaced by the
>actual value in the CTest test name. If this behavior is undesirable (e.g.
>because the value strings are unwieldy), this option will suppress this
>behavior.
Which appears to be a decent default, but not when the parameter is a pointer,
in which case the test name will contain some hex values.
Reviewed By: genevievehelsel
Differential Revision: D27713222
fbshipit-source-id: 0f15b24d04817384ff975ad7b07e16b744e1eb2e
Summary: Add a new `http.verbose` config option that turns on verbose output for libcurl (similar to the output printed by `curl -v`). This can be very useful for debugging HTTP issues.
Reviewed By: DurhamG
Differential Revision: D27693304
fbshipit-source-id: 2ad7a08889f40ffbcd2f14ac9c21d70433629da4
Summary: Make this method match the behavior of `remotefileslog.memcachestore` and cache the `edenapistore` instead of constructing a new one each time. Right now this doesn't matter too much because we currently only call this once when setting up the Rust `revisionstore`, but it would be good to avoid creating multiple instances if we do start using this elsewhere.
Reviewed By: DurhamG
Differential Revision: D27684210
fbshipit-source-id: 7987f603c79758902b4740dd8b46d26a25baec93
Summary:
This diff causes memcache to be disabled when `remotefilelog.cachekey` is set to the empty string, thereby allowing memcache to be disabled on the command line with `--config remotefilelog.cachekey=''`. This is useful when testing data-layer changes.
Previously, the only way to do this was to add `%unset cachekey` to the `remotefilelog` section of your `hgrc`, which was a bit tedious compared to just using a `--config` flag.
Reviewed By: DurhamG
Differential Revision: D27683782
fbshipit-source-id: 3e0434e98a32db916a07935e8b26f70317f50286
Summary: The error is not going to have a message in many cases leading to crashes.
Reviewed By: quark-zju
Differential Revision: D27637119
fbshipit-source-id: 135b133371916dddf0c47a84f00957a8b8fdfe92
Summary:
It looks like nfs_test is tripping the nightly pyre infer job causing it to not
publish diff that increase our typing coverage. Let's manually type it to
unblock the nightly job.
Reviewed By: genevievehelsel
Differential Revision: D27682093
fbshipit-source-id: a32df9f5b8eeaef2006de7d64f5adadb763402e8
Summary:
We hammer MySQL during GC - slow down so that bad connections to
servers that are no longer current are dropped from the pool
https://fb.workplace.com/groups/scm.mononoke/permalink/1407064449656126/?comment_id=1408378062858098 justifies setting the MySQL max ages to 1 second - it works around a MyRouter issue where it *should* reconnect us to a different host, but doesn't.
Reviewed By: krallin
Differential Revision: D27500583
fbshipit-source-id: e900925e1f0d65828613fe3e3d7f4128dc7cde82
Summary: SQLBlob doesn't benefit from sharing a pool with other MySQL users, but does benefit from more aggressive connection timeouts. Give it its own pool, which we can tweak later.
Reviewed By: krallin
Differential Revision: D27651133
fbshipit-source-id: 8f5216ec0506b217f9365babfe1ebac00f68a9a9
Summary:
Like it says in the title. This is a place where we use timeseries so we might
as well use that shared crate.
Reviewed By: mzr
Differential Revision: D27678389
fbshipit-source-id: 9b5d4980a1ddb5ce2a01c8ef417c78b1c3da80b7
Summary:
I'd like to be able to track time series for access within Mononoke. The
underlying use case here is that I want to be able to track the max count of
connections in our SQL connection pools over time (and possibly other things in
the future).
Now, the obvious question is: why am I rolling my own? Well, as it turns out,
there isn't really an implementation of this that I can reuse:
- You might expect to be able to track the max of a value via fb303, but you
can't:
https://www.internalfb.com/intern/diffusion/FBS/browse/master/fbcode/fb303/ExportType.h?commit=0405521ec858e012c0692063209f3e13a2671043&lines=26-29
- You might go look in Folly, but you'll find that the time series there only
supports tracking Sum & Average, but I want my timeseries to track Max (and
in fact I'd like it to be sufficiently flexible to track anything I want):
https://www.internalfb.com/intern/diffusion/FBS/browse/master/fbcode/folly/stats/BucketedTimeSeries.h
It's not the first time I've ran into a need for something like this. I needed
it in RendezVous to track connections over the last 2 N millisecond intervals,
and we needed it in metagit for host draining as well (note that the
implementation here is somewhat inspired by the implementation there).
Reviewed By: mzr
Differential Revision: D27678388
fbshipit-source-id: ba6d244b8bb848d4e1a12f9c6f54e3aa729f6c9c
Summary:
This is breaking with a warning because there's a method called `intersperse`
that might be introduced in the std lib:
```
stderr: error: a method with this name may be added to the standard library in the future
--> eden/mononoke/hgproto/src/sshproto/response.rs:48:53
|
48 | let separated_results = escaped_results.intersperse(separator);
| ^^^^^^^^^^^
|
note: the lint level is defined here
--> eden/mononoke/hgproto/src/lib.rs:14:9
```
This should fix it.
Reviewed By: ikostia
Differential Revision: D27705212
fbshipit-source-id: 5f2f641ea6561c838288c8b158c6d9e134ec0724
Summary:
`const_cstr::ConstCStr` is represented internally as a fat pointer with fixed size: `&'static str`. See https://docs.rs/const-cstr/0.3.0/const_cstr/struct.ConstCStr.html. Notably this is **different** from the representation of `std::ffi::CStr`, which is a dynamically sized type and normally passed around behind a reference, as `&CStr`. Using `&ConstCStr` in signatures, which is effectively like `&'a &'static CStr`, is confusing due to the discrepancy between the two relatedly named types. Additionally having two different lifetimes involved -- the static lifetime of the underlying bytes, and the short lifetime of the fat pointer -- is unnecessarily confusing when async code and a language boundary are involved.
The utf8-cstr crate uses what seems like a better representation to me than the const-cstr crate. See https://docs.rs/utf8-cstr/0.1.6/utf8_cstr/struct.Utf8CStr.html. `Utf8CStr` is the dynamically sized type, just like `CStr`. Then `&'static Utf8CStr` is how it would commonly be passed around, just like `&CStr`.
Reviewed By: krallin
Differential Revision: D27698169
fbshipit-source-id: ffe172c2c2fc77aeab6b0a0a8aed3e3c196098cc
Summary: Migrate the codebase away from the ad-hoc `folly::uint64ToBufferUnsafe` and to `folly::to_ascii_decimal` which is intended for these cases.
Reviewed By: WillerZ
Differential Revision: D27281875
fbshipit-source-id: 0c98749e4aed9c873853eed2221cf54a89279ff4
Summary:
The hashes that are passed in as parameters to the hash-to-location function
may not be hashes that actually exist. This change updates the code so that
we don't return an error when an unknown hash is passed in. The unknown
hash will be skipped in the list of results.
Reviewed By: quark-zju
Differential Revision: D27526758
fbshipit-source-id: 8bf9b7a134a6a8a4f78fa0df276f847d922472f5
