Summary:
The patches to these crates have been upstreamed.
allow-large-files
Reviewed By: jsgf
Differential Revision: D29891894
fbshipit-source-id: a9f2ee0744752b689992b770fc66b6e66b3eda2b
Summary:
In previous diff we started creating deletion commits on megarepo mainline.
This is not great since it breaks bisects, and this diff avoids that.
The way it does it is the following:
1) First do the same thing we did before - create deletion commit, and then
create a merge commit with p1 as deletion commit and p2 as an addition commit.
Let's call it "fake merge", since this commit won't be used for our mainline
2) Generate manifest for our "fake merge", and then use this manifest to
generate bonsai diff. But this time make p1 an old target commit (i.e. remove
deleted commit as if it never exited).
3) Use generated bonsai diff to create a commit.
So in short we split the procedure in two - first generate and validate the
resulting manifest (this is what we use "fake merge" commit for), and then
generate bonsai changeset using this manifest. It's unfortunate that in order
to generate resulting manifest we actually need to create commit and save it to
blobstore. If we had in-memory manifests we could have avoided that, but alas
we don't have them yet.
This way of creating bonsai changesets is a bit unconventional, but I think it has the benefit of relying on tools that we have confidence that they work (i.e. bonsai_diff), and we don't need to reimplement all the bonsai logic again
Reviewed By: mitrandir77
Differential Revision: D29633340
fbshipit-source-id: eebdb0e4db5abbab9346c575b662b7bb467497c4
Summary:
This is just updating the os_info crate to my fork with a fix for Centos
Stream: https://github.com/stanislav-tkach/os_info/pull/267
Reviewed By: quark-zju
Differential Revision: D29410043
fbshipit-source-id: 3642e704f5a056e75fee4421dc59020fde13ed5e
Summary:
Pull in a patch which fixes writing out an incorrect entsize for the
`SHT_GNU_versym` section:
ddbae72082
Reviewed By: igorsugak
Differential Revision: D29248208
fbshipit-source-id: 90bbaa179df79e817e3eaa846ecfef5c1236073a
Summary: revert the zstd crates back to previous version
Reviewed By: johansglock
Differential Revision: D29038514
fbshipit-source-id: 3cbc31203052034bca428441d5514557311b86ae
Summary: Update to latest version. This includes a patch to async-compression crate from [my PR updating it](https://github.com/Nemo157/async-compression/pull/125), I will remove once the crate is released.
Reviewed By: mitrandir77
Differential Revision: D28897019
fbshipit-source-id: 07c72f2880e7f8b85097837d084178c6625e77be
Summary:
This is a precaution. add_sync_target can create a very branchy repository, and
I'm not sure how well Mononoke is going to handle deriving of these commits by
all mononoke hosts at once (in particular, I'm worried about traversal that has
to be done by all hosts in parallel). In theory it should work fine, but
deriving data during add_sync_target call should be a reasonable thing to do
anyway.
While working on that I noticed that "git" derived data is not supported by derived data utils, and it was causing test failures. I don't think there's any reason to not have TreeHandle in derived data utils, so I'm adding it now.
Reviewed By: farnz
Differential Revision: D28831052
fbshipit-source-id: 5f60ac5b93d2c38b4afa0f725c6908edc8b98b18
Summary:
Linkfiles are supported by grepo tool - this is a symlink to a file in a sub
git repo.
Previously add_sync_target ignored them - let's fix it now.
Reviewed By: mitrandir77
Differential Revision: D28704032
fbshipit-source-id: 49e66200c0ce8c46d6fb7d81d5f948a5842a064c
Summary:
This is the very first version of add_sync_target method. It's very naive - it
just creates a single merge commit, and it doesn't handle all the necessary
functionality (e.g. linkfiles) and it doesn't do all the necessary checks yet.
TODOs show the missing functionality.
However this implementation it should be good enough as the first version, and
we can continue to extend it.
Reviewed By: mitrandir77
Differential Revision: D28677365
fbshipit-source-id: a8af6b92ced285ce4d012843f591d5c29584669d
Summary: It will be used in the next diffs, let's move it to a common file
Reviewed By: mitrandir77
Differential Revision: D28675768
fbshipit-source-id: 78c21e378053a157d09ee9d032576a434a52c912
Summary:
Simple test that syncs a single commit from a source to a target.
A few notes
1) I want to use test Mononoke instance, but I can't initialize them in another
crate because of cfg(test). I removed cfg(test) to make it possible.
2) I initialized megarepo mapping in TestRepoFactory so that all tables
were in the same db. It's not strictly necessary, but makes initialization a bit simpler.
Reviewed By: mitrandir77
Differential Revision: D28444865
fbshipit-source-id: f39c917806709606ce8e5a1c1158f186d239d8b8
Summary: These will be used in the next diffs, let's add initialization here.
Reviewed By: ikostia
Differential Revision: D28409734
fbshipit-source-id: f656db8259f28559df52562f0590382d89f1f0c0
Summary:
This struct is intended to be a single entry-point to the megarepo logic. It is also intended to be owned directly by scs_server without the `Mononoke` struct (from `mononoke_api`) intermediary. In effect, this means that mononoke server won't be affected by `MegarepoApi` at all.
Apart from adding this struct, this diff also adds instantiation of prod `AsyncMethodRequestQueue` and wires it up to the scs_server to enqueue and poll requests.
Reviewed By: StanislavGlebik
Differential Revision: D28356563
fbshipit-source-id: b67ee48387d794fd333d106d3ffd40124086c97e
