|
1185.1.29
by Robert Collins
merge merge tweaks from aaron, which includes latest .dev |
1 |
* Write-once store of files identified by globally-unique names |
2 |
(e.g. hashes or UUIDs). |
|
3 |
||
4 |
Simplest option is to just dump them in a directory. |
|
5 |
||
6 |
Optionally do delta-compression between similar/related files; or |
|
7 |
build this on top of deltas. |
|
8 |
||
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 |
|
11 |
by hash. |
|
12 |
||
13 |
- Reconstruct a revision by pulling out the manifest and then all |
|
14 |
the individual files. |
|
15 |
||
16 |
- Manipulate working copy of inventory by add/mv/remove/commands. |
|
17 |
||
18 |
* Retrieve deltas |
|
19 |
||
20 |
- Calculate diffs between two file versions, just by getting them |
|
21 |
from the store. |
|
22 |
||
23 |
- Retrieve deltas between any two revisions: requires looking for |
|
24 |
changes to the structure of the tree, and then text changes for |
|
25 |
anything inside it. |
|
26 |
||
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. |
|
29 |
||
30 |
- Calculate diff between a previous revision and the working copy. |
|
31 |
||
32 |
* Commit and retrieve revisions |
|
33 |
||
34 |
- Revisions hold metadata (date, committer, comment, optional |
|
35 |
parents, merged patches), and a pointer to the inventory. |
|
36 |
||
37 |
- Stored in a write-once store. |
|
38 |
||
39 |
* Branch holds a linear history of revisions. |
|
40 |
||
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 |
|
44 |
consistent. |
|
45 |
||
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.) |
|
49 |
||
50 |
- Can add a new revision to the end. |
|
51 |
||
52 |
- By indexing into this can translate between 0-based revision |
|
53 |
numbers and revision ids. |
|
54 |
||
55 |
- By walking through and looking at revision dates can find |
|
56 |
revisions in a particular date range. |
|
57 |
||
58 |
* Calculations on branch histories: |
|
59 |
||
60 |
- Find if one branch is a prefix of another. |
|
61 |
||
62 |
- Find the latest common ancestor of another. |
|
63 |
||
64 |
* Three-way merge between revisions |
|
65 |
||
66 |
- Resolve shape of directory |
|
67 |
||
68 |
- Then resolve textual conflicts |
|
69 |
||
70 |
* Pull/push changes when they perfectly match |
|
71 |
||
72 |
- Possible when the destination is a prefix of the source |
|
73 |
||
74 |
- Just move all revisions, manifests and texts across, and |
|
75 |
||
76 |
* Merge all changes from one branch into another |
|
77 |
||
78 |
* Signatures applied to revisions |
|
79 |
||
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. |
|
84 |
||
85 |
- If it is unknown, untrusted, revoked, etc, that is reported. |
|
86 |
Depending on a paranoia level it may cause the operation to |
|
87 |
abort. |
|
88 |