Sometimes it is more efficient to perform multiple operations at once
and store those in the collaborative object graph together.
Change the contents to be a non-empty sequence of byte sequences,
i.e. NonEmpty<Vec<u8>>. These are stored as blobs in a git tree in
order by their index in the non-empty sequence. They are, in turn,
retrieved in order of their original index.
Change the conversion of an `EntryWithClock` to return a non-empty
sequence of `Op`s, which are in turn used to apply many changes in
each `from_history` implementation.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
This is a minimal port of the collaborative objects code from
radicle-link[0].
A `CollaborativeObject` is made up of a `History` of `Change`s that
are expected to be stored in a `git` backend.
The library exposes a CRU series of functions `create`, `get`, `list`,
and `update`.
This implementation differs, to previous one, in that it does not
assume any kind of identity system -- its only assumption is that
identities have an identifier and can be addressed in the `git`
database. This means that it does not require an `author` to be passed
in and it only uses the `resource` (previously `authorizing_identity`)
to store its content-address in the `Change`.
It also foregoes any caching to simplify the port and not make any
early optimisation assumptions.
[0]: https://github.com/radicle-dev/radicle-link/tree/master/cob
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
Fintan Halpenny
Alexis Sellier