Summary:
This is not only the newer, more specific type -- it also makes a couple
of upcoming diffs more straightforward.
Reviewed By: StanislavGlebik
Differential Revision: D7622906
fbshipit-source-id: 4e453b827512c538f4f9777ae4d24627f3b124cf
Summary:
Turns out this trait is actually really useful. In this case it'll be
used to generate blobstore types.
Reviewed By: StanislavGlebik
Differential Revision: D7608152
fbshipit-source-id: 792de037c8b028172f868b9b035ede3db9a39788
Summary:
This is going to make life more convenient in upcoming diffs, when these strings are going to be used to generate blobstore keys.
The switch to lowercase is to make those blobstore keys look nicer.
The switch to string literals is because Rust really supports strings a lot better than it does bytestrings. In particular, `concat!` for literals works with strings, but there's no equivalent for bytestring literals. For current purposes the two are equivalent -- there's no runtime cost to using a string literal here.
Reviewed By: StanislavGlebik
Differential Revision: D7598616
fbshipit-source-id: f2fa543429921cca5fd8dc354ea11000fdab3f76
Summary:
If there are multiple parents, it is important to know which parent to
follow for copy information.
Reviewed By: StanislavGlebik
Differential Revision: D7597811
fbshipit-source-id: 74bb0080671b18beb5483b978016bf66a9496967
Summary:
This will help in case we ever need to abandon this format in the
future.
Reviewed By: jsgf
Differential Revision: D7483425
fbshipit-source-id: 0cca098ca861cca0994c06709849ececffb38fc5
Summary:
The current structure makes defining new manifests really verbose and
doesn't easily support nested manifests. Make it really simple: either accept a
path map or a description (a csv).
Also switch to a `BTreeMap` to allow lookups in the next diff.
This is unfortunately hard to separate out because all the bits are
interconnected.
Reviewed By: StanislavGlebik
Differential Revision: D7531115
fbshipit-source-id: ca0fa35d4e0ac6a4e23adb2a7d2b5679ce52b643
Summary:
Since `FileType` now exists, the `Type` enum can use it instead of
defining its own stuff.
Reviewed By: farnz
Differential Revision: D7526046
fbshipit-source-id: 3b8eb5502bee9bc410ced811dc019c1ce757633f
Summary: Very similar to serialize and deserialize for bonsai changesets.
Reviewed By: farnz
Differential Revision: D7380859
fbshipit-source-id: 42567ae3c2e52597b3708871358165ec54a8c04a
Summary: This name is less misleading. Thanks markbt for suggesting it.
Reviewed By: farnz
Differential Revision: D7380821
fbshipit-source-id: 96abb846fd8979cc322e1f176d15caf24bb00874
Summary: The compact_protocol code is from jsgf.
Reviewed By: farnz
Differential Revision: D7365901
fbshipit-source-id: 4cef925ad60c579188ab016fed3f027b3944a3a1
Summary:
This also means that a direct conversion from a byte slice to a Blake2
is no longer desirable. Forcing people to go through the typed hashes seems
quite desirable.
Reviewed By: farnz
Differential Revision: D7365900
fbshipit-source-id: 36f4afd5a53f857c8952c636b0db0b4b509a6f44
Summary:
Since none of the typed hashes use it, NULL hashes aren't going to be
used anywhere in the system.
Reviewed By: farnz
Differential Revision: D7365068
fbshipit-source-id: d67c021a6c04ca1a120264ec88943a5b35d9b8c4
Summary:
I'm still filling this in, but thought I'd put this up for review
right now.
I haven't done the Thrift conversions yet -- those will happen soon.
Reviewed By: farnz
Differential Revision: D7300834
fbshipit-source-id: 96f5f67dbd3d6bafffa127ad93acd178292ec788
Summary:
A lot of Mononoke expects MPath instances to be non-empty, and some
Mononoke code wants empty MPaths. Have formerly-empty `MPath` instances be
represented as `None` instead.
There's a bit of a wart where we have to check for some instances being empty
even though they should never be. This is not a regression -- this is actually
a deficiency in our current type hierarchy being exposed. `Entry` can sometimes
represent a root manifest, but a root path and a root manifest will never be
joined together in practice. We may want to figure out a better way to
represent that in the future.
Also clean up a bunch of code that checks for empty `MPath` instances. That
just isn't possible any more -- yay.
Reviewed By: StanislavGlebik
Differential Revision: D7359048
fbshipit-source-id: 684f908dabaa06cb25b1dd33f4fd7bb021cb5e1b
Summary:
In this case it's super convenient to just use `RepoPath` instances,
so just do that.
The next diff will remove the ability to create `MPath` instances entirely.
Reviewed By: StanislavGlebik
Differential Revision: D7358368
fbshipit-source-id: 8915e765d7e879ec35abac9dfe3ea9653520395d
Summary:
Lots of places specifically want a non-empty `MPath`, and earlier those cases
weren't type-checked. Now `Option<MPath>` stands for an empty `MPath`. In the
next diff `MPath::empty()` will go away and the only way to represent an
`MPath` that doesn't exist will be with `Option<MPath>`.
Reviewed By: farnz
Differential Revision: D7350970
fbshipit-source-id: 1612aec67134e7a0ebad15dbaa93b5ea972f8ddf
Summary:
The `Option<&MPathElement>` type is more general -- it's easy to
convert from `&Option<MPathElement>` to it, but the other way around can
require a clone.
Reviewed By: farnz
Differential Revision: D7339161
fbshipit-source-id: 0c8ab57a19bc330245c612e3e0e3651e368ab8cb
Summary:
Most places expect MPathElements to be non-empty, and it's good to
have static type checking for that.
The only uses could easily be replaced.
Reviewed By: farnz
Differential Revision: D7337587
fbshipit-source-id: cf700b609478bba1f881a77c82a53f8b9863ad7f
Summary:
A Mononoke tiny changeset is going to have a list of these file
changes.
Reviewed By: farnz
Differential Revision: D7336315
fbshipit-source-id: 25d9908cf825e665ac7605435ce5a4056f221e17
Summary:
For now this just wraps a blob, but in the future this will have
special support for large files.
Reviewed By: farnz
Differential Revision: D7336121
fbshipit-source-id: f4c9e216efdd250fde90307264c1931de97d8592
Summary: Represented as a chrono datetime in Rust and an (i64, i32) pair in Thrift.
Reviewed By: jsgf
Differential Revision: D7325332
fbshipit-source-id: 22c3b17961ffb0b4fdb4e6e8aece3b257b3c718e
Summary:
External code should consider these identifiers opaque -- the fact
that they're hashes is an implementation detail.
Also a "blob" is too generic here -- what we're talking about is file contents.
In the future (e.g. for 10GB+ files) the content hash might point to something
more complicated than file contents.
Reviewed By: farnz
Differential Revision: D7320932
fbshipit-source-id: 11a781345a1973f0af8222b809004daa948c3a47
Summary:
I think it makes a lot of logical sense to have three separate hash
types:
* `ChangesetId` for changesets
* `UnodeHash` for unodes
* `BlobHash` for file blobs
These three are never going to mix. Note that manifests and file unodes are
going to mix in e.g. tree manifest unodes.
Reviewed By: farnz
Differential Revision: D7300742
fbshipit-source-id: 688b410f7a5304fdd5ab3a6800137632887f97b9
Summary:
As part of conversion from Thrift to native Rust data structures,
verify that they're valid.
Reviewed By: farnz
Differential Revision: D7297264
fbshipit-source-id: d0bb46a5a5ed2113d9616a56fc100943802cbc1f
Summary:
Also add conversions to and from the Thrift type to the Rust type.
There are tradeoffs around having parallel sets of data structures vs using
Thrift as the only data structure, but I believe that for these hashes (and
transitively, anything that includes them), having a separate type is best.
That's because:
* these hashes are going to be used all over the place, and using a
heap-allocated vector is just a waste. Even a `SmallVec` that's inline will
consume some extra memory for storing the fact that it's inline.
* something has to verify that the vector is valid, and it's nice for that
to be encoded in the type system.
Reviewed By: farnz
Differential Revision: D7285116
fbshipit-source-id: e887414862821076ef0b11e2d0cb0783be897d4a
Summary:
While writing Thrift deserialization code I realized there was nothing
that actually checked that MPathElement instances don't have embedded nulls or
slashes.
Reviewed By: farnz
Differential Revision: D7296838
fbshipit-source-id: 6a23d559da11e5e935e23d7b9a13f58894efaf62
Summary:
These hashes will be the used throughout Mononoke's data model.
Also add mocks.
Note that a `UnodeHash` cannot be null.
Reviewed By: farnz
Differential Revision: D7260955
fbshipit-source-id: d5be5c67848e7b93218a26282e0a757708df7e62
Summary:
This is ripped off pretty much directly from the `Sha1` type in
`mercurial-types`.
Reviewed By: StanislavGlebik
Differential Revision: D7205225
fbshipit-source-id: facb243735d858c68886ad932920024eaf3de536
Summary:
These are types that are going to be used throughout Mononoke -- I'm hoping to
avoid references to current Mercurial data structures in here.
For now, the only module I've moved is part of the `path` module. The
Mercurial-specific `fsencode` bits have been kept in mercurial-types (though
maybe they should move to `mercurial`?)
In the future, this module will also include definitions for unodes, etc.
Reviewed By: jsgf
Differential Revision: D7188722
fbshipit-source-id: fc097ca12c38a787f83e35af9b8dd308f2b910ea
