9
Check has multiple responsibilities:
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.
20
Ideally one check invocation can do all these things.
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.
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.
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.
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.
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
added
removed
doc/developers/check.txt
