pub struct Repository<T> { /* private fields */ }Expand description
The repository side of a run, over whichever store holds its state.
The two flavours below are this one behaviour with a different store under it, so neither can learn something the other does not know.
Implementations§
Source§impl Repository<MemoryStore<VcsState>>
impl Repository<MemoryStore<VcsState>>
Source§impl Repository<FileStore<VcsState>>
impl Repository<FileStore<VcsState>>
Sourcepub fn create(path: impl Into<PathBuf>) -> Result<Self>
pub fn create(path: impl Into<PathBuf>) -> Result<Self>
A repository provider keeping its state at path: whatever is already
there, or nothing.
Attaching rather than replacing, so a second provider over the same path picks up what the first one left — which is what a journey driving several invocations reaches for this flavour to get.
Trait Implementations§
Source§impl<T: Debug> Debug for Repository<T>
impl<T: Debug> Debug for Repository<T>
Source§impl<T: Store<VcsState>> Vcs for Repository<T>
impl<T: Store<VcsState>> Vcs for Repository<T>
Source§fn publish(
&self,
token: &SessionToken,
request: &PublishRequest,
hosting: &dyn Hosting,
) -> Result<Publication>
fn publish( &self, token: &SessionToken, request: &PublishRequest, hosting: &dyn Hosting, ) -> Result<Publication>
Publish a session’s branch, as far as a provider honestly can.
The host side is performed rather than described: a change request is really
opened against the Hosting this was handed, really adopted when one is
already open, and really merged under the policy — so the six host methods
are exercised and what the host recorded is what a journey reads back.
The repository side is not, and none of it is claimed. There is no origin to
fetch from, no tree to run a gate in, no push, and no lock to queue behind,
so no fetch, gate-started, gate-verdict, push, lock-wait,
lock-acquired, or merge-queued event is emitted. What is emitted is what
was decided: the change that was opened, and the merge that landed.