← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/check.txt

Turn completion assertions into separate methods.

Many common assertions used to be expressed as arguments to the complete
method.  This makes the checks more explicit, and the code easier to read.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/check.txt
1
 
Check Notes
2
 
===========
3
 
 
4
 
.. contents:: :local:
5
 
 
6
 
Overview
7
 
--------
8
 
 
9
 
Check has multiple responsibilities:
10
 
 
11
 
* Ensure that the data as recorded on disk is accessible intact and unaltered.
12
 
* Ensure that a branch/repository/tree/whatever is ready for upgrade.
13
 
* Look for and report on recorded-data issues where previous bzr's, or changing
14
 
  situations have lead so some form of inconsistency.
15
 
* Report sufficient information for a user to either fix the issue themselves
16
 
  or report a bug that will hopefully be sufficiently detailed we can fix based
17
 
  on the initial report.
18
 
* Not scare users when run if everything is okey-dokey.
19
 
 
20
 
Ideally one check invocation can do all these things.
21
 
 
22
 
Repository
23
 
----------
24
 
 
25
 
Things that can go wrong:
26
 
* Bit errors or alterations may occur in raw data.
27
 
* Data that is referenced may be missing
28
 
* There could be a lot of garbage in upload etc.
29
 
* File graphs may be inconsistent with inventories and parents.
30
 
* The revision graph cache can be inconsistent with the revision data.
31
 
 
32
 
Branch
33
 
------
34
 
 
35
 
Things that can go wrong:
36
 
* Tag or tip revision ids may be missing from the repo.
37
 
* The revno tip cache may be wrong.
38
 
* Various URLS could be problematic (not inaccessible, just invalid)
39
 
* Stacked-on branch could be inaccessible.
40
 
 
41
 
Tree
42
 
----
43
 
 
44
 
Things that can go wrong:
45
 
* Bit errors in dirstate.
46
 
* Corrupt or invalid shelves.
47
 
* Corrupt dirstates written to disk.
48
 
* Cached inventories might not match repository.
49
 
 
50
 
Duplicate work
51
 
--------------
52
 
 
53
 
If we check every branch in a repo separately we will encounter duplicate
54
 
effort in assessing things like missing tags/tips, revno cache etc.
55
 
 
56
 
Outline of approach
57
 
-------------------
58
 
 
59
 
To check a repository, we scan for branches, open their trees and generate
60
 
summary data. We then collect all the summary data in as compact a form as
61
 
possible and do a detailed check on the repository, calling back out to branch
62
 
and trees as we encounter the actual data that that tree/branch requires to
63
 
perform its check.