Summary: hgsql can only use traditional revlog. Disable changelog migration for it.
Reviewed By: kulshrax
Differential Revision: D26891252
fbshipit-source-id: 36c5a448d4fcad15b3415e4534448a945f6d0b4b
Summary: We weren't passing a repo path when initially loading the repo's config in `clidispatch`. This meant that the resulting `ConfigSet` didn't contain values from the shared-repo `.hgrc.dynamic`. Evidently, some other code path in Python would eventually add these values, but this meant that pure-Rust commands could not see config values set via dynamicconfig. Passing the path fixes the problem.
Reviewed By: DurhamG
Differential Revision: D26508980
fbshipit-source-id: 65f187d18098a08c81325e78cb02a8ed854c739a
Summary:
See the previous diff for motivation. This removes bookmarks that are
ancestor of master, too. This is important in practice.
Reviewed By: DurhamG
Differential Revision: D26889412
fbshipit-source-id: 255722ed5b486e88ef56e7e378fae3f1113d5fbe
Summary:
The auto cleanup was conservative. It keeps `::draft()`. But that means
ancestors of public commits are not cleaned up. Not all release branches
branch off the master branch.
Reviewed By: DurhamG
Differential Revision: D26889413
fbshipit-source-id: c6a8e3f32cf1f7d2ffe74b7ecd183f4e583949bb
Summary:
Normally we prohibit landing commits that might accidentally
change the x-repo mapping. However we do want to allow landing commits like
that to backup repos, because backup repos should have all commits as their
counterpart repositories.
This change also has another side-effect - we don't call `load_additional_changeset()`
which can be very expensive for backup repos because of the issues in configuration -
in particular, we don't have `hooks_ancestors_of` option set, and that caused all ancestors to be considered
as "additional changesets". It would make since more properly later.
Differential Revision: D26883910
fbshipit-source-id: 07ceb7b96bc6cae851ac6ff57071eff5cef387e4
Summary:
This allows for errors raised in these cases to be retried. Most notable is
the timeout error.
Reviewed By: johansglock
Differential Revision: D26855441
fbshipit-source-id: 6137ed1755072d43dbdd25fa092ddb21c8669aa3
Summary:
No timeout is set up by default so the process wait forever when reading bytes
in cases where the connection is lost somehow.
Reviewed By: johansglock
Differential Revision: D26855443
fbshipit-source-id: d741f73e7186fe862f3d78a806f3219c2cbe7e0a
Summary:
Abort one of the most general exceptions in Mercurial. In theory it should be
something that isn't handled. We can say at least that it shouldn't be retried.
For thing that may be transient it is better to use a different type of
exception. NetworkError is something is checked and retries in a few places so
that seems like a natural candidate.
Reviewed By: johansglock
Differential Revision: D26855444
fbshipit-source-id: f15c723293a416b5f44a6592927e3500f3b0b7d5
Summary: Timeouts are another class of errors that are relevant.
Reviewed By: johansglock
Differential Revision: D26855442
fbshipit-source-id: 8ebb83714fa3d7a2f4efcbed8bd512c98301b49d
Summary:
We ran into an issue while uploading too many blobs at once to darkstorm repo.
We were able to workaround this issue by spawning less blobstore writes at
once.
It's still a bit unclear why this issue happens exactly, but I'd like to make
the number of concurrent uploaded blobs configurable so that we can tweak it if
necessary.
Differential Revision: D26883061
fbshipit-source-id: 57c0d6fc51548b3c7404ebd55b5e07deba9e0601
Summary:
I ran into an interesting issue - git and Mononoke/mercurial store timezones
differently.
Git - From https://fburl.com/utwmsmcu:
```
Git internal format
It is <unix timestamp> <time zone offset>, where <unix timestamp> is the number of seconds since the UNIX epoch. <time zone offset> is a positive or negative offset from UTC. **For example CET (which is 1 hour ahead of UTC) is +0100.**
```
Note that CET (which is to the east of utc) is stored as +0100.
Hg - now from `hg help dates`
```
This is the internal representation format for dates. The first number is
the number of seconds since the epoch (1970-01-01 00:00 UTC). The second
is the offset of the local timezone, in seconds **west of UTC (negative if the timezone is east of UTC)**.
```
that means that CET will be stored as -0100 i.e. with negative sign.
Mononoke - see https://fburl.com/diffusion/zf59f76j
We use FixedOffset::west_opt, and from docs (https://docs.rs/chrono/0.4.19/chrono/offset/struct.FixedOffset.html#method.west_opt)
```
Makes a new FixedOffset for the Western Hemisphere with given timezone difference. The negative secs means the Eastern Hemisphere.
Returns None on the out-of-bound secs.
```
So in order for mercurial and git to actually mean the same timezone, we need to multiply it by -1.
(note that hggit seem to be doing the same thing - https://fburl.com/code/pgdj5f2s).
You might wonder why mercurial's "hg log" now outputs the same timezone value as git - it converts it before outputting (https://fburl.com/code/ltmc66a1).
Reviewed By: krallin
Differential Revision: D26848463
fbshipit-source-id: fbd8c370565f5b663b438d0c11bddf39d090a16b
Summary: The goal is to reduce load on tokio scheduler by using threads & channels instead of spawning new task every time
Reviewed By: DurhamG
Differential Revision: D26801249
fbshipit-source-id: a8d9accc721c7ffc981fd538c06ab8cbd908f715
Summary:
AsyncVfs provides async vfs interface.
It will be used in the native checkout instead of current use case that spawns blocking tokio tasks for VFS action
Reviewed By: quark-zju
Differential Revision: D26801250
fbshipit-source-id: bb26c4fc8acac82f4b55bb3f2f3964a6d0b64014
Summary: This function is now internal details of vfs, and is not used outside of it. Making it private so it won't be accessed outside
Reviewed By: quark-zju
Differential Revision: D26801251
fbshipit-source-id: 03434e235978fa0745128d90ea0c5975ea662ff1
Summary:
On EdenFS startup, it would always print the following warning:
W0304 16:32:36.103828 642480 EdenConfig.cpp:424] Ignoring unknown section in eden config: /etc/eden/edenfs.rc, key: prefetch-profiles
This is due to that particular config not being specified in EdenConfig.h. By
adding it to EdenConfig.h, the warning disappear.
Reviewed By: genevievehelsel
Differential Revision: D26834504
fbshipit-source-id: 409de118f015226f839cce3ff79a4a2d5b9b43a3
Summary:
Fast-track some tricky-to-avoid getxattr requests from the kernel
itself. It would be best to avoid the context switch entirely, but in
lieu of that, at least don't log anything or enter our more expensive
FUSE handling path.
This is follow-up to D24039130 (37f030ba72), which apparently did not completely
eliminate POSIX ACL lookups.
Reviewed By: xavierd
Differential Revision: D26803589
fbshipit-source-id: 18cba8e3ffc45516e6458872e408ed29a562c7a8
Summary:
Taking a fuse_setattr_in arg means that it can only be used on FUSE, and while
FUSE has been the only backend on UNIX for a while, this is changing with NFS
being added. Thus, we need to find a solution that isn't tied to FUSE.
The solution is fairly simple, let's simply have a struct with optional fields
that needs changing, FUSE and NFS will set these to what needs changing.
Reviewed By: chadaustin
Differential Revision: D26742213
fbshipit-source-id: 16e3e8cdd22d88ace43485d9e3744280de1ee8ad
Summary:
As its name implies FuseDispatcher::Attr is purely FUSE related and thus
shouldn't affect the inodes. It also removes a blocker to using setattr for
NFS.
Reviewed By: chadaustin
Differential Revision: D26742214
fbshipit-source-id: 41a67af0c948d969d5a427f24718de5b134980da
Summary:
This merely adds the types needed for the SYMLINK RPC, the implementation will
follow.
Reviewed By: kmancini
Differential Revision: D26737273
fbshipit-source-id: 4ed3029304fe64892e88bc05a64b4b3b19fd5460
Summary: This is merely adding the type, the implementation will follow.
Reviewed By: kmancini
Differential Revision: D26737271
fbshipit-source-id: 42de7873b271a2bf9499f1274bca50f23dc1016b
Summary:
Both READDIR and READDIRPLUS RPC (and other) are using lists as a way to have
an unsized array of values. From a behavior perspective, this is similar to an
array of XdrOptionalValue but without it being prefixed by a size, and with an
additional last element being empty.
To simplify writing these RPC, let's add this XdrList type.
Reviewed By: kmancini
Differential Revision: D26729816
fbshipit-source-id: 8d14bbc6f0513aac51d65625e5751cedc2071a0b
Summary:
The recent change to make list-bookmarks be served from the warm bookmark cache
made this test flaky.
Ensure the warm bookmark cache has been populated with all of the bookmarks
before starting the tests.
Reviewed By: StanislavGlebik
Differential Revision: D26847951
fbshipit-source-id: 7e26c3745600fa8c1a337e8a8b47af6cca2f3eff
Summary:
Turned out that some of our commit cloud commits dont have an entry in changesets table,
but they do have an entry in bonsai_hg_mapping. It happens because of transient mysql errors.
Because of the mess we have in how we determine if a given hg changeset is present in mononoke or not,
this broken commit is considered backed up by commit cloud, while in reality its impossible to pull this commit.
This diff fixes it by first inserting changeset entry, and then bonsai_hg_mapping.
This way if an insertion of a changeset entry fails then the commit is not
considered to exist at all.
If an insertion of bonsai hg mapping fails, then commit is considered to be inserted but the whole
operation (it can be "hg cloud sync" for example) is considered failed. In this case hg client will
try to reupload this commit later.
But there's one caveat.
Hg changesets and bonsai changesets are not always round-trippable i.e.
generating from bonsai to hg and hg to bonsai might not always
produce the same results. So it's possible to push a commit which inserts changeset entry but not hg bonsai entry,
then we accidentally derive hg changeset from this bonsai and it's different from what user has pushed to mononoke.
This could lead to problems later (i.e. re-pushing the same commit again later would fail).
Another solution (inserting bonsai hg mapping and changeset entry in the same transaction) could make this issue
less likely, but it won't eliminate it completely. We discussed it, and I think it probably make sense to go
with the simpler fix first, since this problem should happen rarely in practice
(and if it happens often then we should prioritize fixing it).
Reviewed By: krallin
Differential Revision: D26845779
fbshipit-source-id: 61f8b0d835dc4aa0130e6be632c43307ff4a771f
Summary: Like it says in the title. I also replaced one of our status codes that was wrong.
Reviewed By: johansglock
Differential Revision: D26844865
fbshipit-source-id: b8c1261d0077cf5dc006827e16667e382db7d189
Summary: This diff removes the split between manually managed and autocargo managed Cargo.toml files in `eden/scm/lib`, now all files are autogenerated.
Reviewed By: quark-zju
Differential Revision: D26830884
fbshipit-source-id: 3a5d8409a61347c7650cc7d8192fa426c03733dc
