1
* Write-once store of files identified by globally-unique names
2
(e.g. hashes or UUIDs).
4
Simplest option is to just dump them in a directory.
6
Optionally do delta-compression between similar/related files; or
7
build this on top of deltas.
9
* Tree manifests/inventories which say which files should be assembled at
10
particular points to build a tree. These too can be stored indexed
13
- Reconstruct a revision by pulling out the manifest and then all
16
- Manipulate working copy of inventory by add/mv/remove/commands.
20
- Calculate diffs between two file versions, just by getting them
23
- Retrieve deltas between any two revisions: requires looking for
24
changes to the structure of the tree, and then text changes for
27
- Deltas may be either stored or calculated on demand. They can be
28
put in the store just indexed by the from and to manifest id.
30
- Calculate diff between a previous revision and the working copy.
32
* Commit and retrieve revisions
34
- Revisions hold metadata (date, committer, comment, optional
35
parents, merged patches), and a pointer to the inventory.
37
- Stored in a write-once store.
39
* Branch holds a linear history of revisions.
41
- This is mostly redundant; we could just remember the current base
42
revision and walk backwards from there. But it still seems
43
possibly useful to hold; we can check that the two are always
46
(This suggests that we actually *could* do ``switch`` if we
47
really wanted to, by replacing the revision history and head
48
revision. But I don't think it's a good idea.)
50
- Can add a new revision to the end.
52
- By indexing into this can translate between 0-based revision
53
numbers and revision ids.
55
- By walking through and looking at revision dates can find
56
revisions in a particular date range.
58
* Calculations on branch histories:
60
- Find if one branch is a prefix of another.
62
- Find the latest common ancestor of another.
64
* Three-way merge between revisions
66
- Resolve shape of directory
68
- Then resolve textual conflicts
70
* Pull/push changes when they perfectly match
72
- Possible when the destination is a prefix of the source
74
- Just move all revisions, manifests and texts across, and
76
* Merge all changes from one branch into another
78
* Signatures applied to revisions
80
- There is a separable module for checking a signature: this is
81
passed the claimed author, changeset, date. This needs to fetch
82
an appropriate key, decide if it is trusted to correspond to that
83
author, is not revoked, etc.
85
- If it is unknown, untrusted, revoked, etc, that is reported.
86
Depending on a paranoia level it may cause the operation to