2020-12-12 08:00:42 +00:00
|
|
|
// Copyright 2020 Google LLC
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
// you may not use this file except in compliance with the License.
|
|
|
|
// You may obtain a copy of the License at
|
|
|
|
//
|
|
|
|
// https://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
//
|
|
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
// See the License for the specific language governing permissions and
|
|
|
|
// limitations under the License.
|
|
|
|
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
use std::collections::BTreeMap;
|
2020-12-12 08:00:42 +00:00
|
|
|
use std::fmt::Debug;
|
|
|
|
use std::fs;
|
|
|
|
use std::fs::File;
|
2021-03-14 17:46:35 +00:00
|
|
|
use std::io::{ErrorKind, Write};
|
2020-12-12 08:00:42 +00:00
|
|
|
use std::path::PathBuf;
|
|
|
|
|
2022-02-10 06:01:13 +00:00
|
|
|
use blake2::{Blake2b512, Digest};
|
2021-07-11 17:58:01 +00:00
|
|
|
use itertools::Itertools;
|
2022-05-02 15:53:50 +00:00
|
|
|
use protobuf::{Message, MessageField};
|
2020-12-12 08:00:42 +00:00
|
|
|
use tempfile::{NamedTempFile, PersistError};
|
|
|
|
|
2021-09-12 06:52:38 +00:00
|
|
|
use crate::backend::{CommitId, MillisSinceEpoch, Timestamp};
|
2021-06-14 07:27:42 +00:00
|
|
|
use crate::file_util::persist_content_addressed_temp_file;
|
2020-12-12 08:00:42 +00:00
|
|
|
use crate::op_store::{
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
BranchTarget, OpStore, OpStoreError, OpStoreResult, Operation, OperationId, OperationMetadata,
|
2021-11-17 21:06:02 +00:00
|
|
|
RefTarget, View, ViewId, WorkspaceId,
|
2020-12-12 08:00:42 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
impl From<std::io::Error> for OpStoreError {
|
|
|
|
fn from(err: std::io::Error) -> Self {
|
|
|
|
OpStoreError::Other(err.to_string())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl From<PersistError> for OpStoreError {
|
|
|
|
fn from(err: PersistError) -> Self {
|
|
|
|
OpStoreError::Other(err.to_string())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-05-02 15:53:50 +00:00
|
|
|
impl From<protobuf::Error> for OpStoreError {
|
|
|
|
fn from(err: protobuf::Error) -> Self {
|
2020-12-12 08:00:42 +00:00
|
|
|
OpStoreError::Other(err.to_string())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct SimpleOpStore {
|
|
|
|
path: PathBuf,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl SimpleOpStore {
|
|
|
|
pub fn init(store_path: PathBuf) -> Self {
|
|
|
|
fs::create_dir(store_path.join("views")).unwrap();
|
|
|
|
fs::create_dir(store_path.join("operations")).unwrap();
|
|
|
|
Self::load(store_path)
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn load(store_path: PathBuf) -> Self {
|
|
|
|
SimpleOpStore { path: store_path }
|
|
|
|
}
|
|
|
|
|
|
|
|
fn view_path(&self, id: &ViewId) -> PathBuf {
|
|
|
|
self.path.join("views").join(id.hex())
|
|
|
|
}
|
|
|
|
|
|
|
|
fn operation_path(&self, id: &OperationId) -> PathBuf {
|
|
|
|
self.path.join("operations").join(id.hex())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn not_found_to_store_error(err: std::io::Error) -> OpStoreError {
|
|
|
|
if err.kind() == ErrorKind::NotFound {
|
|
|
|
OpStoreError::NotFound
|
|
|
|
} else {
|
|
|
|
OpStoreError::from(err)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl OpStore for SimpleOpStore {
|
|
|
|
fn read_view(&self, id: &ViewId) -> OpStoreResult<View> {
|
2021-06-14 07:18:38 +00:00
|
|
|
let path = self.view_path(id);
|
2020-12-12 08:00:42 +00:00
|
|
|
let mut file = File::open(path).map_err(not_found_to_store_error)?;
|
|
|
|
|
2021-03-15 03:43:02 +00:00
|
|
|
let proto: crate::protos::op_store::View = Message::parse_from_reader(&mut file)?;
|
2020-12-12 08:00:42 +00:00
|
|
|
Ok(view_from_proto(&proto))
|
|
|
|
}
|
|
|
|
|
|
|
|
fn write_view(&self, view: &View) -> OpStoreResult<ViewId> {
|
|
|
|
let temp_file = NamedTempFile::new_in(&self.path)?;
|
|
|
|
|
|
|
|
let proto = view_to_proto(view);
|
|
|
|
let mut proto_bytes: Vec<u8> = Vec::new();
|
|
|
|
proto.write_to_writer(&mut proto_bytes)?;
|
|
|
|
|
|
|
|
temp_file.as_file().write_all(&proto_bytes)?;
|
|
|
|
|
2022-02-10 06:01:13 +00:00
|
|
|
let id = ViewId::new(Blake2b512::digest(&proto_bytes).to_vec());
|
2020-12-12 08:00:42 +00:00
|
|
|
|
2021-06-14 07:27:42 +00:00
|
|
|
persist_content_addressed_temp_file(temp_file, self.view_path(&id))?;
|
2020-12-12 08:00:42 +00:00
|
|
|
Ok(id)
|
|
|
|
}
|
|
|
|
|
|
|
|
fn read_operation(&self, id: &OperationId) -> OpStoreResult<Operation> {
|
2021-06-14 07:18:38 +00:00
|
|
|
let path = self.operation_path(id);
|
2020-12-12 08:00:42 +00:00
|
|
|
let mut file = File::open(path).map_err(not_found_to_store_error)?;
|
|
|
|
|
2021-03-15 03:43:02 +00:00
|
|
|
let proto: crate::protos::op_store::Operation = Message::parse_from_reader(&mut file)?;
|
2020-12-12 08:00:42 +00:00
|
|
|
Ok(operation_from_proto(&proto))
|
|
|
|
}
|
|
|
|
|
|
|
|
fn write_operation(&self, operation: &Operation) -> OpStoreResult<OperationId> {
|
|
|
|
let temp_file = NamedTempFile::new_in(&self.path)?;
|
|
|
|
|
|
|
|
let proto = operation_to_proto(operation);
|
|
|
|
let mut proto_bytes: Vec<u8> = Vec::new();
|
|
|
|
proto.write_to_writer(&mut proto_bytes)?;
|
|
|
|
|
|
|
|
temp_file.as_file().write_all(&proto_bytes)?;
|
|
|
|
|
2022-02-10 06:01:13 +00:00
|
|
|
let id = OperationId::new(Blake2b512::digest(&proto_bytes).to_vec());
|
2020-12-12 08:00:42 +00:00
|
|
|
|
2021-06-14 07:27:42 +00:00
|
|
|
persist_content_addressed_temp_file(temp_file, self.operation_path(&id))?;
|
2020-12-12 08:00:42 +00:00
|
|
|
Ok(id)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-12-24 07:12:18 +00:00
|
|
|
fn timestamp_to_proto(timestamp: &Timestamp) -> crate::protos::op_store::Timestamp {
|
|
|
|
let mut proto = crate::protos::op_store::Timestamp::new();
|
2022-05-02 15:53:50 +00:00
|
|
|
proto.millis_since_epoch = timestamp.timestamp.0;
|
|
|
|
proto.tz_offset = timestamp.tz_offset;
|
2020-12-12 08:00:42 +00:00
|
|
|
proto
|
|
|
|
}
|
|
|
|
|
2020-12-24 07:12:18 +00:00
|
|
|
fn timestamp_from_proto(proto: &crate::protos::op_store::Timestamp) -> Timestamp {
|
2020-12-12 08:00:42 +00:00
|
|
|
Timestamp {
|
|
|
|
timestamp: MillisSinceEpoch(proto.millis_since_epoch),
|
|
|
|
tz_offset: proto.tz_offset,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn operation_metadata_to_proto(
|
|
|
|
metadata: &OperationMetadata,
|
2020-12-24 07:12:18 +00:00
|
|
|
) -> crate::protos::op_store::OperationMetadata {
|
|
|
|
let mut proto = crate::protos::op_store::OperationMetadata::new();
|
2022-05-02 15:53:50 +00:00
|
|
|
proto.start_time = MessageField::some(timestamp_to_proto(&metadata.start_time));
|
|
|
|
proto.end_time = MessageField::some(timestamp_to_proto(&metadata.end_time));
|
|
|
|
proto.description = metadata.description.clone();
|
|
|
|
proto.hostname = metadata.hostname.clone();
|
|
|
|
proto.username = metadata.username.clone();
|
|
|
|
proto.tags = metadata.tags.clone();
|
2020-12-12 08:00:42 +00:00
|
|
|
proto
|
|
|
|
}
|
|
|
|
|
2020-12-24 07:12:18 +00:00
|
|
|
fn operation_metadata_from_proto(
|
|
|
|
proto: &crate::protos::op_store::OperationMetadata,
|
|
|
|
) -> OperationMetadata {
|
2022-05-02 15:53:50 +00:00
|
|
|
let start_time = timestamp_from_proto(&proto.start_time);
|
|
|
|
let end_time = timestamp_from_proto(&proto.end_time);
|
|
|
|
let description = proto.description.to_owned();
|
|
|
|
let hostname = proto.hostname.to_owned();
|
|
|
|
let username = proto.username.to_owned();
|
|
|
|
let tags = proto.tags.clone();
|
2020-12-12 08:00:42 +00:00
|
|
|
OperationMetadata {
|
|
|
|
start_time,
|
|
|
|
end_time,
|
|
|
|
description,
|
|
|
|
hostname,
|
|
|
|
username,
|
2021-05-09 06:37:05 +00:00
|
|
|
tags,
|
2020-12-12 08:00:42 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-12-24 07:12:18 +00:00
|
|
|
fn operation_to_proto(operation: &Operation) -> crate::protos::op_store::Operation {
|
|
|
|
let mut proto = crate::protos::op_store::Operation::new();
|
2022-05-02 15:53:50 +00:00
|
|
|
proto.view_id = operation.view_id.as_bytes().to_vec();
|
2020-12-12 08:00:42 +00:00
|
|
|
for parent in &operation.parents {
|
2021-11-17 22:13:41 +00:00
|
|
|
proto.parents.push(parent.to_bytes());
|
2020-12-12 08:00:42 +00:00
|
|
|
}
|
2022-05-02 15:53:50 +00:00
|
|
|
proto.metadata = MessageField::some(operation_metadata_to_proto(&operation.metadata));
|
2020-12-12 08:00:42 +00:00
|
|
|
proto
|
|
|
|
}
|
|
|
|
|
2020-12-24 07:12:18 +00:00
|
|
|
fn operation_from_proto(proto: &crate::protos::op_store::Operation) -> Operation {
|
2021-11-17 22:13:41 +00:00
|
|
|
let operation_id_from_proto = |parent: &Vec<u8>| OperationId::new(parent.clone());
|
2020-12-12 08:00:42 +00:00
|
|
|
let parents = proto.parents.iter().map(operation_id_from_proto).collect();
|
2021-11-17 22:13:41 +00:00
|
|
|
let view_id = ViewId::new(proto.view_id.clone());
|
2022-05-02 15:53:50 +00:00
|
|
|
let metadata = operation_metadata_from_proto(&proto.metadata);
|
2020-12-12 08:00:42 +00:00
|
|
|
Operation {
|
|
|
|
view_id,
|
|
|
|
parents,
|
|
|
|
metadata,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-12-24 07:12:18 +00:00
|
|
|
fn view_to_proto(view: &View) -> crate::protos::op_store::View {
|
|
|
|
let mut proto = crate::protos::op_store::View::new();
|
2021-11-17 21:06:02 +00:00
|
|
|
for (workspace_id, commit_id) in &view.checkouts {
|
|
|
|
proto
|
|
|
|
.checkouts
|
|
|
|
.insert(workspace_id.as_str().to_string(), commit_id.to_bytes());
|
|
|
|
}
|
2020-12-12 08:00:42 +00:00
|
|
|
for head_id in &view.head_ids {
|
2021-11-17 22:20:54 +00:00
|
|
|
proto.head_ids.push(head_id.to_bytes());
|
2020-12-12 08:00:42 +00:00
|
|
|
}
|
2021-01-16 18:42:22 +00:00
|
|
|
for head_id in &view.public_head_ids {
|
2021-11-17 22:20:54 +00:00
|
|
|
proto.public_head_ids.push(head_id.to_bytes());
|
2021-01-16 18:42:22 +00:00
|
|
|
}
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
|
|
|
|
for (name, target) in &view.branches {
|
|
|
|
let mut branch_proto = crate::protos::op_store::Branch::new();
|
2022-05-02 15:53:50 +00:00
|
|
|
branch_proto.name = name.clone();
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
if let Some(local_target) = &target.local_target {
|
2022-05-02 15:53:50 +00:00
|
|
|
branch_proto.local_target = MessageField::some(ref_target_to_proto(local_target));
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
}
|
|
|
|
for (remote_name, target) in &target.remote_targets {
|
|
|
|
let mut remote_branch_proto = crate::protos::op_store::RemoteBranch::new();
|
2022-05-02 15:53:50 +00:00
|
|
|
remote_branch_proto.remote_name = remote_name.clone();
|
|
|
|
remote_branch_proto.target = MessageField::some(ref_target_to_proto(target));
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
branch_proto.remote_branches.push(remote_branch_proto);
|
|
|
|
}
|
|
|
|
proto.branches.push(branch_proto);
|
|
|
|
}
|
|
|
|
|
|
|
|
for (name, target) in &view.tags {
|
|
|
|
let mut tag_proto = crate::protos::op_store::Tag::new();
|
2022-05-02 15:53:50 +00:00
|
|
|
tag_proto.name = name.clone();
|
|
|
|
tag_proto.target = MessageField::some(ref_target_to_proto(target));
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
proto.tags.push(tag_proto);
|
|
|
|
}
|
|
|
|
|
2021-07-11 17:58:01 +00:00
|
|
|
for (git_ref_name, target) in &view.git_refs {
|
2021-01-03 08:26:57 +00:00
|
|
|
let mut git_ref_proto = crate::protos::op_store::GitRef::new();
|
2022-05-02 15:53:50 +00:00
|
|
|
git_ref_proto.name = git_ref_name.clone();
|
|
|
|
git_ref_proto.target = MessageField::some(ref_target_to_proto(target));
|
2021-01-03 08:26:57 +00:00
|
|
|
proto.git_refs.push(git_ref_proto);
|
|
|
|
}
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
|
2021-11-28 20:29:04 +00:00
|
|
|
if let Some(git_head) = &view.git_head {
|
2022-05-02 15:53:50 +00:00
|
|
|
proto.git_head = git_head.to_bytes();
|
2021-11-28 20:29:04 +00:00
|
|
|
}
|
|
|
|
|
2020-12-12 08:00:42 +00:00
|
|
|
proto
|
|
|
|
}
|
|
|
|
|
2020-12-24 07:12:18 +00:00
|
|
|
fn view_from_proto(proto: &crate::protos::op_store::View) -> View {
|
2021-11-17 21:06:02 +00:00
|
|
|
let mut view = View::default();
|
|
|
|
// For compatibility with old repos before we had support for multiple working
|
|
|
|
// copies
|
|
|
|
if !proto.checkout.is_empty() {
|
|
|
|
view.checkouts.insert(
|
|
|
|
WorkspaceId::default(),
|
|
|
|
CommitId::new(proto.checkout.clone()),
|
|
|
|
);
|
|
|
|
}
|
|
|
|
for (workspace_id, commit_id) in &proto.checkouts {
|
|
|
|
view.checkouts.insert(
|
|
|
|
WorkspaceId::new(workspace_id.clone()),
|
|
|
|
CommitId::new(commit_id.clone()),
|
|
|
|
);
|
|
|
|
}
|
2022-05-03 03:45:02 +00:00
|
|
|
for head_id_bytes in &proto.head_ids {
|
2021-11-17 22:20:54 +00:00
|
|
|
view.head_ids.insert(CommitId::from_bytes(head_id_bytes));
|
2020-12-12 08:00:42 +00:00
|
|
|
}
|
2022-05-03 03:45:02 +00:00
|
|
|
for head_id_bytes in &proto.public_head_ids {
|
2021-01-16 18:42:22 +00:00
|
|
|
view.public_head_ids
|
2021-11-17 22:20:54 +00:00
|
|
|
.insert(CommitId::from_bytes(head_id_bytes));
|
2021-01-16 18:42:22 +00:00
|
|
|
}
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
|
2022-05-03 03:45:02 +00:00
|
|
|
for branch_proto in &proto.branches {
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
let local_target = branch_proto
|
|
|
|
.local_target
|
|
|
|
.as_ref()
|
2021-10-11 19:52:57 +00:00
|
|
|
.map(ref_target_from_proto);
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
|
|
|
|
let mut remote_targets = BTreeMap::new();
|
2022-05-03 03:45:02 +00:00
|
|
|
for remote_branch in &branch_proto.remote_branches {
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
remote_targets.insert(
|
|
|
|
remote_branch.remote_name.clone(),
|
2022-05-02 15:53:50 +00:00
|
|
|
ref_target_from_proto(&remote_branch.target),
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
view.branches.insert(
|
|
|
|
branch_proto.name.clone(),
|
|
|
|
BranchTarget {
|
|
|
|
local_target,
|
|
|
|
remote_targets,
|
|
|
|
},
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2022-05-03 03:45:02 +00:00
|
|
|
for tag_proto in &proto.tags {
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
view.tags.insert(
|
|
|
|
tag_proto.name.clone(),
|
2022-05-02 15:53:50 +00:00
|
|
|
ref_target_from_proto(&tag_proto.target),
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2022-05-03 03:45:02 +00:00
|
|
|
for git_ref in &proto.git_refs {
|
2022-05-02 15:53:50 +00:00
|
|
|
if let Some(target) = git_ref.target.as_ref() {
|
|
|
|
view.git_refs
|
|
|
|
.insert(git_ref.name.clone(), ref_target_from_proto(target));
|
2021-07-11 17:58:01 +00:00
|
|
|
} else {
|
|
|
|
// Legacy format
|
|
|
|
view.git_refs.insert(
|
|
|
|
git_ref.name.clone(),
|
2021-11-17 22:20:54 +00:00
|
|
|
RefTarget::Normal(CommitId::new(git_ref.commit_id.clone())),
|
2021-07-11 17:58:01 +00:00
|
|
|
);
|
|
|
|
}
|
2021-01-03 08:26:57 +00:00
|
|
|
}
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
|
2021-11-28 20:29:04 +00:00
|
|
|
if !proto.git_head.is_empty() {
|
|
|
|
view.git_head = Some(CommitId::new(proto.git_head.clone()));
|
|
|
|
}
|
|
|
|
|
2020-12-12 08:00:42 +00:00
|
|
|
view
|
|
|
|
}
|
2021-07-11 17:58:01 +00:00
|
|
|
|
|
|
|
fn ref_target_to_proto(value: &RefTarget) -> crate::protos::op_store::RefTarget {
|
|
|
|
let mut proto = crate::protos::op_store::RefTarget::new();
|
|
|
|
match value {
|
|
|
|
RefTarget::Normal(id) => {
|
2021-11-17 22:20:54 +00:00
|
|
|
proto.set_commit_id(id.to_bytes());
|
2021-07-11 17:58:01 +00:00
|
|
|
}
|
|
|
|
RefTarget::Conflict { removes, adds } => {
|
|
|
|
let mut ref_conflict_proto = crate::protos::op_store::RefConflict::new();
|
|
|
|
for id in removes {
|
2021-11-17 22:20:54 +00:00
|
|
|
ref_conflict_proto.removes.push(id.to_bytes());
|
2021-07-11 17:58:01 +00:00
|
|
|
}
|
|
|
|
for id in adds {
|
2021-11-17 22:20:54 +00:00
|
|
|
ref_conflict_proto.adds.push(id.to_bytes());
|
2021-07-11 17:58:01 +00:00
|
|
|
}
|
|
|
|
proto.set_conflict(ref_conflict_proto);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
proto
|
|
|
|
}
|
|
|
|
|
|
|
|
fn ref_target_from_proto(proto: &crate::protos::op_store::RefTarget) -> RefTarget {
|
|
|
|
match proto.value.as_ref().unwrap() {
|
2022-05-02 15:53:50 +00:00
|
|
|
crate::protos::op_store::ref_target::Value::CommitId(id) => {
|
2021-11-17 22:20:54 +00:00
|
|
|
RefTarget::Normal(CommitId::from_bytes(id))
|
2021-07-11 17:58:01 +00:00
|
|
|
}
|
2022-05-02 15:53:50 +00:00
|
|
|
crate::protos::op_store::ref_target::Value::Conflict(conflict) => {
|
2021-07-11 17:58:01 +00:00
|
|
|
let removes = conflict
|
|
|
|
.removes
|
|
|
|
.iter()
|
2021-11-17 22:20:54 +00:00
|
|
|
.map(|id_bytes| CommitId::from_bytes(id_bytes))
|
2021-07-11 17:58:01 +00:00
|
|
|
.collect_vec();
|
|
|
|
let adds = conflict
|
|
|
|
.adds
|
|
|
|
.iter()
|
2021-11-17 22:20:54 +00:00
|
|
|
.map(|id_bytes| CommitId::from_bytes(id_bytes))
|
2021-07-11 17:58:01 +00:00
|
|
|
.collect_vec();
|
|
|
|
RefTarget::Conflict { removes, adds }
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2021-07-31 00:47:30 +00:00
|
|
|
|
|
|
|
#[cfg(test)]
|
|
|
|
mod tests {
|
|
|
|
use tempfile::TempDir;
|
|
|
|
|
|
|
|
use super::*;
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn test_read_write_view() {
|
|
|
|
let temp_dir = TempDir::new().unwrap();
|
|
|
|
let store = SimpleOpStore::init(temp_dir.path().to_owned());
|
2021-11-17 22:20:54 +00:00
|
|
|
let head_id1 = CommitId::from_hex("aaa111");
|
|
|
|
let head_id2 = CommitId::from_hex("aaa222");
|
|
|
|
let public_head_id1 = CommitId::from_hex("bbb444");
|
|
|
|
let public_head_id2 = CommitId::from_hex("bbb555");
|
|
|
|
let branch_main_local_target = RefTarget::Normal(CommitId::from_hex("ccc111"));
|
|
|
|
let branch_main_origin_target = RefTarget::Normal(CommitId::from_hex("ccc222"));
|
|
|
|
let branch_deleted_origin_target = RefTarget::Normal(CommitId::from_hex("ccc333"));
|
|
|
|
let tag_v1_target = RefTarget::Normal(CommitId::from_hex("ddd111"));
|
|
|
|
let git_refs_main_target = RefTarget::Normal(CommitId::from_hex("fff111"));
|
2021-07-31 00:47:30 +00:00
|
|
|
let git_refs_feature_target = RefTarget::Conflict {
|
2021-11-17 22:20:54 +00:00
|
|
|
removes: vec![CommitId::from_hex("fff111")],
|
|
|
|
adds: vec![CommitId::from_hex("fff222"), CommitId::from_hex("fff333")],
|
2021-07-31 00:47:30 +00:00
|
|
|
};
|
2021-11-17 21:06:02 +00:00
|
|
|
let default_checkout_id = CommitId::from_hex("abc111");
|
|
|
|
let test_checkout_id = CommitId::from_hex("abc222");
|
2021-07-31 00:47:30 +00:00
|
|
|
let view = View {
|
|
|
|
head_ids: hashset! {head_id1, head_id2},
|
|
|
|
public_head_ids: hashset! {public_head_id1, public_head_id2},
|
view: add support for ref-based branches and tags to model
I've finally decided to copy Git's branching model (issue #21), except
that I'm letting the name identify the branch across
remotes. Actually, now that I think about, that makes them more like
Mercurial's "bookmarks". Each branch will record the commit it points
to locally, as well as the commits it points to on each remote (as far
as the repo knows, of course). Those records are effectively the same
thing as Git's "remote-tracking branches"; the difference is that we
consider them the same branch. Consequently, when you pull a new
branch from a remote, we'll create that branch locally.
For example, if you pull branch "main" from a remote called "origin",
that will result in a local branch called "main", and also a record of
the position on the remote, which we'll show as "main@origin" in the
CLI (not part of this commit). If you then update the branch locally
and also pull a new target for it from "origin", the local "main"
branch will be divergent. I plan to make it so that pushing "main"
will update the remote's "main" iff it was currently at "main@origin"
(i.e. like using Git's `git push --force-with-lease`).
This commit adds a place to store information about branches in the
view model. The existing git_refs field will be used as input for the
branch information. For example, we can use it to tell if
"refs/heads/main" has changed and how it has changed. We will then use
that ref diff to update our own record of the "main" branch. That will
come later. In order to let git_refs take a back seat, I've also added
tags (like Git's lightweight tags) to the model in this commit.
I haven't ruled out *also* having some more persistent type of
branches (like Mercurials branches or topics).
2021-07-15 08:31:48 +00:00
|
|
|
branches: btreemap! {
|
|
|
|
"main".to_string() => BranchTarget {
|
|
|
|
local_target: Some(branch_main_local_target),
|
|
|
|
remote_targets: btreemap! {
|
|
|
|
"origin".to_string() => branch_main_origin_target,
|
|
|
|
}
|
|
|
|
},
|
|
|
|
"deleted".to_string() => BranchTarget {
|
|
|
|
local_target: None,
|
|
|
|
remote_targets: btreemap! {
|
|
|
|
"origin".to_string() => branch_deleted_origin_target,
|
|
|
|
}
|
|
|
|
},
|
|
|
|
},
|
|
|
|
tags: btreemap! {
|
|
|
|
"v1.0".to_string() => tag_v1_target,
|
|
|
|
},
|
2021-07-31 00:47:30 +00:00
|
|
|
git_refs: btreemap! {
|
|
|
|
"refs/heads/main".to_string() => git_refs_main_target,
|
|
|
|
"refs/heads/feature".to_string() => git_refs_feature_target
|
|
|
|
},
|
2021-11-28 20:29:04 +00:00
|
|
|
git_head: Some(CommitId::from_hex("fff111")),
|
2021-11-17 21:06:02 +00:00
|
|
|
checkouts: hashmap! {
|
|
|
|
WorkspaceId::default() => default_checkout_id,
|
|
|
|
WorkspaceId::new("test".to_string()) => test_checkout_id,
|
|
|
|
},
|
2021-07-31 00:47:30 +00:00
|
|
|
};
|
|
|
|
let view_id = store.write_view(&view).unwrap();
|
|
|
|
let read_view = store.read_view(&view_id).unwrap();
|
|
|
|
assert_eq!(read_view, view);
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn test_read_write_operation() {
|
|
|
|
let temp_dir = TempDir::new().unwrap();
|
|
|
|
let store = SimpleOpStore::init(temp_dir.path().to_owned());
|
|
|
|
let operation = Operation {
|
2021-11-17 22:13:41 +00:00
|
|
|
view_id: ViewId::from_hex("aaa111"),
|
2021-07-31 00:47:30 +00:00
|
|
|
parents: vec![
|
2021-11-17 22:13:41 +00:00
|
|
|
OperationId::from_hex("bbb111"),
|
|
|
|
OperationId::from_hex("bbb222"),
|
2021-07-31 00:47:30 +00:00
|
|
|
],
|
|
|
|
metadata: OperationMetadata {
|
|
|
|
start_time: Timestamp {
|
|
|
|
timestamp: MillisSinceEpoch(123456789),
|
|
|
|
tz_offset: 3600,
|
|
|
|
},
|
|
|
|
end_time: Timestamp {
|
|
|
|
timestamp: MillisSinceEpoch(123456800),
|
|
|
|
tz_offset: 3600,
|
|
|
|
},
|
|
|
|
description: "check out foo".to_string(),
|
|
|
|
hostname: "some.host.example.com".to_string(),
|
|
|
|
username: "someone".to_string(),
|
|
|
|
tags: hashmap! {
|
|
|
|
"key1".to_string() => "value1".to_string(),
|
|
|
|
"key2".to_string() => "value2".to_string(),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
};
|
|
|
|
let op_id = store.write_operation(&operation).unwrap();
|
|
|
|
let read_operation = store.read_operation(&op_id).unwrap();
|
|
|
|
assert_eq!(read_operation, operation);
|
|
|
|
}
|
|
|
|
}
|