← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/check.txt

  • Committer: Andrew Bennetts
  • Date: 2010-01-12 03:53:21 UTC
  • mfrom: (4948 +trunk)
  • mto: This revision was merged to the branch mainline in revision 4964.
  • Revision ID: andrew.bennetts@canonical.com-20100112035321-hofpz5p10224ryj3
Merge lp:bzr, resolving conflicts.

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.