/brz/remove-bazaar : contents of doc/developers/check.txt at revision 4332.3.9

: (revision 4332.3.9)

To get this branch, use:

bzr branch
http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

Check Notes
===========

.. contents:: :local:

Overview
--------

Check has multiple responsibilities:

* Ensure that the data as recorded on disk is accessible intact and unaltered.
* Ensure that a branch/repository/tree/whatever is ready for upgrade.
* Look for and report on recorded-data issues where previous bzr's, or changing
  situations have lead so some form of inconsistency.
* Report sufficient information for a user to either fix the issue themselves
  or report a bug that will hopefully be sufficiently detailed we can fix based
  on the initial report.
* Not scare users when run if everything is okey-dokey.

Ideally one check invocation can do all these things.

Repository
----------

Things that can go wrong:
* Bit errors or alterations may occur in raw data.
* Data that is referenced may be missing
* There could be a lot of garbage in upload etc.
* File graphs may be inconsistent with inventories and parents.

Branch
------

Things that can go wrong:
* Tag or tip revision ids may be missing from the repo.
* The revno tip cache may be wrong.
* Various urls could be problematic (not inaccessible, just invalid)
* Stacked-on branch could be inaccessible.

Tree
----

Things that can go wrong:
* Bit errors in dirstate.
* Corrupt or invalid shelves.
* Corrupt dirstates written to disk.
* Cached inventories might not match repository.

Duplicate work
--------------

If we check every branch in a repo separately we will encounter duplicate
effort in assessing things like missing tags/tips, revno cache etc.

Outline of approach
-------------------

To check a repository, we scan for branches, open their trees and generate
summary data. We then collect all the summary data in as compact a form as
possible and do a detailed check on the repository, calling back out to branch
and trees as we encounter the actual data that that tree/branch requires to
perform its check.

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.
	30
	31	Branch
	32	------
	33
	34	Things that can go wrong:
	35	* Tag or tip revision ids may be missing from the repo.
	36	* The revno tip cache may be wrong.
	37	* Various urls could be problematic (not inaccessible, just invalid)
	38	* Stacked-on branch could be inaccessible.
	39
	40	Tree
	41	----
	42
	43	Things that can go wrong:
	44	* Bit errors in dirstate.
	45	* Corrupt or invalid shelves.
	46	* Corrupt dirstates written to disk.
	47	* Cached inventories might not match repository.
	48
	49	Duplicate work
	50	--------------
	51
	52	If we check every branch in a repo separately we will encounter duplicate
	53	effort in assessing things like missing tags/tips, revno cache etc.
	54
	55	Outline of approach
	56	-------------------
	57
	58	To check a repository, we scan for branches, open their trees and generate
	59	summary data. We then collect all the summary data in as compact a form as
	60	possible and do a detailed check on the repository, calling back out to branch
	61	and trees as we encounter the actual data that that tree/branch requires to
	62	perform its check.