/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: 2012-01-18 14:09:19 UTC
  • mto: This revision was merged to the branch mainline in revision 6468.
  • Revision ID: v.ladeuil+lp@free.fr-20120118140919-rlvdrhpc0nq1lbwi
Change set/remove to require a lock for the branch config files.

This means that tests (or any plugin for that matter) do not requires an
explicit lock on the branch anymore to change a single option. This also
means the optimisation becomes "opt-in" and as such won't be as
spectacular as it may be and/or harder to get right (nothing fails
anymore).

This reduces the diff by ~300 lines.

Code/tests that were updating more than one config option is still taking
a lock to at least avoid some IOs and demonstrate the benefits through
the decreased number of hpss calls.

The duplication between BranchStack and BranchOnlyStack will be removed
once the same sharing is in place for local config files, at which point
the Stack class itself may be able to host the changes.

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.