|
4332.3.1
by Robert Collins
Docs for check. |
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. |
|
|
4332.3.12
by Robert Collins
Note another possible error. |
30 |
* The revision graph cache can be inconsistent with the revision data. |
|
4332.3.1
by Robert Collins
Docs for check. |
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. |