/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to doc/developers/check.txt

  • Committer: Vincent Ladeuil
  • Date: 2010-01-25 15:55:48 UTC
  • mto: (4985.1.4 add-attr-cleanup)
  • mto: This revision was merged to the branch mainline in revision 4988.
  • Revision ID: v.ladeuil+lp@free.fr-20100125155548-0l352pujvt5bzl5e
Deploy addAttrCleanup on the whole test suite.

Several use case worth mentioning:

- setting a module or any other object attribute is the majority
by far. In some cases the setting itself is deferred but most of
the time we want to set at the same time we add the cleanup.

- there multiple occurrences of protecting hooks or ui factory
which are now useless (the test framework takes care of that now),

- there was some lambda uses that can now be avoided.

That first cleanup already simplifies things a lot.

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.