Summary:
The bytes 0.5 is a depencency of newer tokio, it's also newer, and thus better.
Staying on 0.4 means that copies between Bytes 0.4 and 0.5 need to be done,
this will be especially bad in the LFS code since 10+MB buffer will have to be
copied...
One main API change is for the configparser. The code used to take Into<Bytes>
for the keys, I switched it to AsRef<[u8]>.
For hg_memcache_client, an extra copy is performed to build a Delta, since this
code uses an old tokio, and is being replaced right now, the effort of
switching to a new tokio and new bytes was not deemed worth it, the copy will
do for now.
Reviewed By: dtolnay
Differential Revision: D20043137
fbshipit-source-id: 395bfc3749a3b1bdfea652262019ac6a086e61e0
Summary:
Moving `store_element` and `get_hgid` from testutil.rs to lib.rs in order to
get rid of some buck build warnings. They are only used in lib.rs.
Reviewed By: markbt
Differential Revision: D19350343
fbshipit-source-id: 081783d753425daaae6fadc38589da5e4e8b745d
Summary:
It makes sense for manifest-tree to expose a testutil version for building a
TreeManifest. No reason for the testutil function to be limited to the crate.
The only issue is that `make_tree` is to generic so we rename the function to
`make_tree_manifest`.
Reviewed By: markbt
Differential Revision: D19350351
fbshipit-source-id: 06fe04d99bf820d3e81417f5a5514aa4b0d282e6
Summary:
Types that are defined by the manifest core crate should have test utilities
defined in the same crate.
This is motivated by various warning in the buck build.
Reviewed By: markbt
Differential Revision: D19350350
fbshipit-source-id: a6a7c3fb54b465aa09a28ff8b70b49a355b328fc
Summary:
Using RepoPath::arbitrary() has a high chance or producing a lot of different
top level directories. The helper method added by this change,
`generate_repo_paths` simulates directories having various files and several
directories.
Reviewed By: quark-zju
Differential Revision: D19321366
fbshipit-source-id: 5c1aec78b6157f3cbea3d0673b29b3a676de88c0
Summary:
The TestStore can be leveraged by methods outside the manifest-tree crate.
Anything that wants to instantiate a manifest for test purposes could
leverage it.
Reviewed By: quark-zju
Differential Revision: D19204894
fbshipit-source-id: 4ac42d09855c70f829feefc6c71dcdbf7211cae3
Summary:
The list functionality is required by EdenFs. We want this functionality
to be well supported by the Manifest.
Reviewed By: quark-zju
Differential Revision: D18870143
fbshipit-source-id: 1ebaa713ff521226e6ace22cbd35cc841d967298
Summary:
Consistency in naming. The general idea is to have Metadata types that don't
contain paths. Then we will have File, Directory and eventually FsNode that
will contain paths.
Reviewed By: quark-zju
Differential Revision: D18870141
fbshipit-source-id: a1f09add7f1c3dd4fa0348693cd3ce2fd5767fa7
Summary:
This rename is going to make it easier to import and use outside of
manifest specific crates.
Reviewed By: quark-zju
Differential Revision: D18870142
fbshipit-source-id: 2f3ea460170308162ee834efc038b2dcedd9e233
Summary:
This isolates the core types in manifest so that it is harder to
create unsound dependencies with specific implementations.
Reviewed By: quark-zju
Differential Revision: D18843133
fbshipit-source-id: 4b866ad84d2e7d0ff2dc4ec6bd65f66548c3fe4a
