← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/layers.txt

  • Committer: Max Bowsher
  • Date: 2010-10-31 14:31:17 UTC
  • mto: This revision was merged to the branch mainline in revision 5521.
  • Revision ID: maxb@f2s.com-20101031143117-57vrfu630yq8a3k2
Fix a slightly odd style of ConfigObj construction to match the prevailing style in bzrlib.

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