~bzr-pqm/bzr/bzr.dev

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