Developer Document Catalog (3.3.22)

# Check Notes

## 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 Breezy’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. * The revision graph cache can be inconsistent with the revision data.

## 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.