jj/lib/protos/op_store.proto
Martin von Zweigbergk 0098edd3d2 op_store: add support for tracking multiple workspaces (#13)
This patch teaches the `View` object to keep track of the checkout in
each workspace. It serializes that information into the `OpStore`. For
compatibility with existing repos, the existing field for a single
workspace's checkout is interpreted as being for the workspace called
"default".

This is just an early step towards support for multiple
workspaces. Remaining things to do:

 * Record the workspace ID somewhere in `.jj/` (maybe in
   `.jj/working_copy/`)

 * Update existing code to use the workspace ID instead of assuming
   it's always "default" as we do after this patch

 * Add a way of indicating in `.jj/` that the repo lives elsewhere and
   make it possible to load a repo from such workspaces

 * Add a command for creating additional workspaces

 * Show each workspace's checkout in log output
2022-02-02 08:15:22 -08:00

91 lines
2.4 KiB
Protocol Buffer

// 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.
syntax = "proto3";
message RefConflict {
repeated bytes removes = 1;
repeated bytes adds = 2;
}
message RefTarget {
oneof value {
bytes commit_id = 1;
RefConflict conflict = 2;
}
}
message RemoteBranch {
string remote_name = 1;
RefTarget target = 2;
}
message Branch {
string name = 1;
// Unset if the branch has been deleted locally.
RefTarget local_target = 2;
// TODO: How would we support renaming remotes while having undo work? If
// the remote name is stored in config, it's going to become a mess if the
// remote is renamed but the configs are left unchanged. Should each remote
// be identified (here and in configs) by a UUID?
repeated RemoteBranch remote_branches = 3;
}
message GitRef {
string name = 1;
// This field is just for historical reasons (before we had the RefTarget
// type). New GitRefs have (only) the target field.
// TODO: Delete support for the old format.
bytes commit_id = 2;
RefTarget target = 3;
}
message Tag {
string name = 1;
RefTarget target = 2;
}
message View {
repeated bytes head_ids = 1;
repeated bytes public_head_ids = 4;
bytes checkout = 2 [deprecated = true];
map<string, bytes> checkouts = 8;
repeated Branch branches = 5;
repeated Tag tags = 6;
// Only a subset of the refs. For example, does not include refs/notes/.
repeated GitRef git_refs = 3;
bytes git_head = 7;
}
message Operation {
bytes view_id = 1;
repeated bytes parents = 2;
OperationMetadata metadata = 3;
}
// TODO: Share with store.proto? Do we even need the timezone here?
message Timestamp {
uint64 millis_since_epoch = 1;
int32 tz_offset = 2;
}
message OperationMetadata {
Timestamp start_time = 1;
Timestamp end_time = 2;
string description = 3;
string hostname = 4;
string username = 5;
map<string, string> tags = 6;
}