Part of bzrlib.reconcile View In Hierarchy
The goal of repository reconciliation is to make any derived data consistent with the core data committed by a user. This can involve reindexing, or removing unreferenced data if that can interfere with queries in a given repository.
Currently this consists of an inventory reweave with revision cross-checks.
|Method||__init__||Construct a RepoReconciler.|
|Method||_reconcile_steps||Perform the steps to reconcile this repository.|
|Method||_reweave_inventory||Regenerate the inventory weave for the repository from scratch.|
|Method||_new_inv_parents||Lookup ghost-filtered parents for revision_key.|
|Method||_change_inv_parents||Adapt a record stream to reconcile the parents.|
|Method||_setup_steps||Setup the markers we need to control the progress bar.|
|Method||_graph_revision||Load a revision into the revision graph.|
|Method||_check_garbage_inventories||Check for garbage inventories which we cannot trust|
|Method||_parent_is_available||True if parent is a fully available revision|
|Method||_reweave_step||Mark a single step of regeneration complete.|
|Parameters||thorough||perform a thorough check which may take longer but will correct non-data loss issues such as incorrect cached data.|
After reconciliation the following attributes document found issues:
inconsistent_parents: The number of revisions in the repository whose ancestry was being reported incorrectly.
garbage_inventories: The number of inventory objects without revisions that were garbage collected.
This is a smart function: it will only do the reweave if doing it will correct data issues. The self.thorough flag controls whether only data-loss causing issues (!self.thorough) or all issues (self.thorough) are treated as requiring the reweave.
We cant trust them because their pre-requisite file data may not be present - all we know is that their revision was not installed.
A fully available revision has a inventory and a revision object in the repository.