Summary: Expose a way to get the shard count for a table. Used later by walker to limit number of steps that try to access the same SQL shard.
Differential Revision: D26497839
fbshipit-source-id: 45ad09527b82a36a76068aace5fff5ef504b7a12
Summary:
This just moves the cheese to use Tokio 0.2 spawn. I have some extra diffs
to actually tackle the code itself here, but I'm planning to do this later.
Reviewed By: StanislavGlebik
Differential Revision: D26511981
fbshipit-source-id: 249d0e667f9930272c9362fc787c977d8d50341e
Summary:
Like it says in the title, this updates us to a newer version of Hyper to avoid
being on one that depends on Tokio 0.1.
Reviewed By: StanislavGlebik
Differential Revision: D26511979
fbshipit-source-id: 325d24f9b4e17fc2e801a2ba79863c0e656870d4
Summary:
This code was a bit hard to convert because just using the 0.2 variants really
doesn't work very well. So, I went ahead and actually refactored it. Here's
what I changed:
- Rather than use a `!Sync` bound to ensure we don't have concurrent access to
the `HgPeer`, I updated this to actually use a `&mut` reference in an `async
fn`. Note that the `!Sync` bound doesn't really do anything here because
it prevented you from instantiating a future concurrently in 2 threads but
nothing prevents you from creating 2 futures and awaiting them concurrently.
The `&mut` reference does (and means we have to wrap this in a Tokio mutex).
- I moved the management of `invalidate()` to the `HgPeer` and not
`AsyncProcess`, given it's always the `HgPeer` that makes the decision to
invalidate.
Reviewed By: StanislavGlebik
Differential Revision: D26511980
fbshipit-source-id: 6deb5be76effbb65cef29c789b9b3e4429326c5f
Summary:
I want to use both future_ext libraries later in this stack, and this will
make it easier.
Reviewed By: StanislavGlebik
Differential Revision: D26510582
fbshipit-source-id: c90fca327697e0e966e8d6ac262115ee69c99112
Summary:
This depends on Tokio for a reexport of futures_old::task (this can't be from
Tokio, and has to live in `future`s, or it wouldn't be possible for futures to
provide `.compat()` on a 0.3 future).
Reviewed By: StanislavGlebik
Differential Revision: D26485715
fbshipit-source-id: 6f334132eb7c7aaa647f8e5052e91c3a38f6d1d8
Summary:
This is using `spawn_future` (aka tokio 0.1 spawn) so it needs changing.
Amusigly, this uses it to spawn a 0.2 future and then it has to pull 0.1
futures to poll it.
Well, anyhow, this fixes this, this removes all the manual instantiation
of a compat runtime (because this never needed one), and it also removes 0.1
futures (because we never needed them).
Reviewed By: StanislavGlebik
Differential Revision: D26485584
fbshipit-source-id: f49c85d2a1dc406e2ad9e7998d9270fe2e6c9f4b
Summary:
Like it says in the title. This is a Tokio 0.1 function, and we want the 0.2
version instead.
Reviewed By: StanislavGlebik
Differential Revision: D26485579
fbshipit-source-id: 95abb28520a61b6dc44a4223a3c6585675a33f3e
Summary: Like it says in the title.
Reviewed By: StanislavGlebik
Differential Revision: D26485581
fbshipit-source-id: 53bc2aea96ef7c073595ba85409f7f6c9b2da516
Summary: I need to use both futures_ext later in this stack. This makes it easier.
Reviewed By: StanislavGlebik
Differential Revision: D26485580
fbshipit-source-id: 589713c7280bf74c9e2b3e018782bf0b7eb821d7
Summary: This lets us ensure we only depend on Tokio 0.2 for timers.
Reviewed By: StanislavGlebik
Differential Revision: D26485590
fbshipit-source-id: e39dbc21dc51070113b3c9df497c2e0bbaa12450
Summary:
Like it says in the title. This one was pretty easy to just convert to 0.3
futures so I did so.
Reviewed By: StanislavGlebik
Differential Revision: D26485577
fbshipit-source-id: 76c751c1004288dda1d7b62866979c9228e0ef34
Summary:
Like it says in the title. Porting anything to Futures 0.3 isn't practical
here so I didn't touch it.
Reviewed By: StanislavGlebik
Differential Revision: D26485585
fbshipit-source-id: 291bf63a6f31d502ac14492151f14bae20009094
Summary: Like it says in the title.
Reviewed By: StanislavGlebik
Differential Revision: D26485573
fbshipit-source-id: f0604760ff73352c7e3601103a84619186cac0d7
Summary: This will make the next diff easier to read.
Reviewed By: StanislavGlebik
Differential Revision: D26485586
fbshipit-source-id: c52d5355c8d9ed742b4de0b1faab460ef6664c69
Summary:
Like it says in the title. This removes places where we use Tokio 0.1 directly
in repo client. We use it for timeouts, so this updates us to Tokio 0.2
timeouts.
Where possible, I've made a few improvements to the code as well:
- I removed timeouts on `future::ok()` because a future that is immediately
ready isn't going to time out.
- I updated some code to async / await where it made sense to do so to avoid
round-tripping through futures 0.1 and 0.2 several times.
One thing that changes here is that we'll show Tokio's error on timeouts (which
says timeout has elapsed) instead of ours, which used to say just "timeout". I
think this doesn't make a big difference.
Reviewed By: StanislavGlebik
Differential Revision: D26485575
fbshipit-source-id: 8158f709bcc52d123a95df541aaeb1ec0fc9c281
Summary: I'd like to use the 0.3 version here so let's get this cleaned up.
Reviewed By: StanislavGlebik
Differential Revision: D26485583
fbshipit-source-id: 1d1ff8e75888e6d874d21195cae7600f171321ac
Summary:
This just spawns stuff. I took a look at also updating the underlying future
to 0.2, but it wasn't trivial so that's better left off as a future task.
Reviewed By: StanislavGlebik
Differential Revision: D26485588
fbshipit-source-id: 02eb6221c36a4b81bf5dae0232be39ae1dd8201a
Summary:
For streams we have `FbStreamExt` and `FbTryStreamExt`. Let's be a little
consistent and do the same with the future extension trait.
Reviewed By: StanislavGlebik
Differential Revision: D26485589
fbshipit-source-id: 5ebbda11d02e16709958a99a806aa70a8354672e
Summary:
OWNERS hook sometimes needs to know the most recent changes made to the OWNERS files. So the user, who was last to change the OWNERS file, can change it again.
This diffs extends `FileContentManager` trait to have a new method `recent_changes`. It derives unode manifest for the given bookmark, finds given paths and gets linknodes. For the linknodes it derives `ChangesetInfo` which is a lightweight version of the bonsai changesets, they contain all the metadata, but don't have a set file changes.
We use unodes here instead of hg manifests, because hg manifests don't have correct linknodes.
Reviewed By: StanislavGlebik
Differential Revision: D26468603
fbshipit-source-id: 78dd0a4e51bee6228de1296eafe7ffa393df2fbe
Summary:
Fix for error:
can only concatenate str (not "NoneType") to str
Reviewed By: quark-zju
Differential Revision: D26523879
fbshipit-source-id: 3d15d72be3444df25fb705ce444d6c3621547551
Summary: makes it a bit easier to work with
Reviewed By: farnz
Differential Revision: D26497840
fbshipit-source-id: bccd248aa9a4caa4e5274f7f9e166ef17196e12f
Summary: Noticed we could relax this constraint and the code could also be cleaned up a little.
Reviewed By: farnz
Differential Revision: D26490859
fbshipit-source-id: 27d3a0e308e593dfa87d5c7d7b47736947f659a8
Summary: Noticed we can relax this constraint
Reviewed By: farnz
Differential Revision: D26490862
fbshipit-source-id: 59e9af6e2b8ebd433f9536e8c0ebec3f401e360e
Summary:
Remove selectivepullaccessedbookmarks feature because it contains bugs and causes many undesired issues.
This was added to migrate existing repos to selective pull and is not needed anymore.
Main effects are:
* if you enable selectivepull for an existing repo, it won't reduce number of subscribed bookmarks.
* some operations like `hg push` or `hg pull -r` in their underlying implementation update all subscribed bookmarks, not just accessed like before.
This drives changes to the tests. Reminder, the bookmark has been marked as "accessed" if the repo has been ever updated to that bookmark.
All tests fixed accordingly.
Reviewed By: markbt
Differential Revision: D26460435
fbshipit-source-id: f839b9f207bfc478a0336ec807b720d35a0bb12e
Summary: Add a cache pool for the new bonsai_svnrev_mapping
Reviewed By: krallin
Differential Revision: D26511043
fbshipit-source-id: feaa1bca525e84ebea7462bcc9a814dcb9e5a478
Summary:
Similarly to what is done for FUSE and ProjectedFS, the dispatcher is the glue
that sits in between the protocol specific bits and the inodes layer.
For now, this only implements "getattr" but it will be filled overtime as more
RPC can be answered properly.
Reviewed By: kmancini
Differential Revision: D26389795
fbshipit-source-id: 19cf3457feec2ebc100e632cb28c20b11fdde26d
Summary: This merely adds the various datastructures needed to implement GETATTR.
Reviewed By: kmancini
Differential Revision: D26389794
fbshipit-source-id: bda557a21386483449c18aa9e52f4f626b73e69f
Summary: A show-build-dir subcommand. Possibly useful for building a project and then running only one test or benchmark binary directly.
Reviewed By: wez
Differential Revision: D26502869
fbshipit-source-id: 0d8f6c42a2bbeb2440503a39c7fc770e3b3e4fff
Summary:
This was added in D26387205 (ca1249c269) to make the treemanifest store usage look
more like the file store usage, but it appears to cause read-after-write
failures. I'm not sure exactly why, but I think it's because something takes a
reference to the old store and writes to it, then something else reads from the
new store. Or vice versa.
Either way, reverting these three lines fixes it.
Reviewed By: singhsrb
Differential Revision: D26497708
fbshipit-source-id: e9afabed8d5f800260e647d5ed1513eed0bc60cd
Summary: Let's treat them like any other ids.
Reviewed By: StanislavGlebik
Differential Revision: D26453408
fbshipit-source-id: fb01bf9ca8871a147a41dded7eed6e3360466a44
Summary: just some boilerplate to make the use from SCS code clean and easy
Reviewed By: StanislavGlebik
Differential Revision: D26453406
fbshipit-source-id: efc280e0be14c3e0f145a489a9fd77b5c0eefa58
Summary: backfill_git_mapping was great for backfilling git mappings, let's use it for svn
Reviewed By: StanislavGlebik
Differential Revision: D26453407
fbshipit-source-id: 3ee61722ac729af5a2fc4187fda3341069bb53f6
Summary: now that we have the bonsai svn mapping let's thread it through blobrepo
Reviewed By: StanislavGlebik
Differential Revision: D26453409
fbshipit-source-id: 4100a9b16ffb3186735e20a766a1ef486d3c26c5
Summary:
Bonsai svnrev mapping will allow us to store the original svn revision number for repos that
were imported from svn at some point in time. This will allow scs_server to
easily respond to queries about commits identified by them.
The code is mostly copypasta from globalrevs
Reviewed By: krallin
Differential Revision: D26424833
fbshipit-source-id: 9825de52c23ab9386de1a9d0e0a9506c0a035a8a
