← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/layers.txt

  • Committer: Martin Pool
  • Date: 2005-07-04 08:06:51 UTC
  • Revision ID: mbp@sourcefrog.net-20050704080651-6ecec49164359e48
- track pending-merges

- unit tests for this

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/layers.txt
 
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