What should reconcile do if a file version's parent is a ghost?
andrew at canonical.com
Wed Sep 26 03:15:18 BST 2007
I'm working on Aaron's branch that teaches reconcile how to fix the corruption
we have in bzr.dev, where the parents recorded in the per-file knit index (i.e.
the per-file version graph) are incorrect when compared to the revision graph.
Aaron's branch includes a test of the following scenario. There is a repository
with some revisions with a single file in them. The exact history is:
- 'rev2' with no parents in the repository;
- 'rev3' has parents 'rev1c' and 'rev1a';
- there are no other revisions in the repository, i.e. 'rev1c' and 'rev1a'
* versions of the file:
- 'rev2' with no parents;
- 'rev1c' with no parents;
- 'rev3' with parents ['rev1c'].
In particular, rev3 of the file has a parent whose revision is a ghost in this
The question is what should reconciling this repository do to rev3 of that file?
Aaron's code changes its parents to be the empty list, but Robert and I are not
sure this is the right thing to do.
Because the revision is a ghost, we can't check the inventory of that revision
against the per-file graph, so we can't be sure that 'rev1c' really is the
ancestor of 'rev3' of this file. But equally we have no reason to believe that
it isn't. So changing the per-file graph seems dubious here.
We *should* verify that 'rev3' of the file is not a delta against 'rev1c' of
that file, because we cannot verify that the inventory of 'rev1c' includes this
file as modified in 'rev1c'. But that doesn't imply that we should modify the
In particular, Jelmer's partial fetch patch will create this situation where the
per-file parents are correct but the inventories required to valid them are
absent in this repository.
So I'm inclined to change this behaviour, but as Aaron explicitly wrote code and
tests to remove the parents in this case I thought I should ask the list. What
do people think? (I'd especially like to hear Aaron's thoughts, of course!)
More information about the bazaar