What should reconcile do if a file version's parent is a ghost?

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Bennetts wrote:
> 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.

I am inclined to be conservative here.  To me index graphs are not
primary data.  I think our primary data are revisions, inventories and
file texts.

I think that it is unfortunate if a repository contains secondary data
(index graphs) that cannot be derived from that primary data, because
that means that two repositories with identical primary data could still
have differences in secondary data.  To an extent, these differences in
secondary data are already a problem that we are trying to fix.  Having
a canonical representation is valuable, in my opinion.

I believe that reducing the parent list to only provable parents has
clear benefits (it allows Andrew's fetch to work), and negligible downsides.

Robert has pointed out that removing unproved parents could change log's
behavior when log is run with a FILE argument.  I believe he is correct.
 But "log FILE"'s use of indices was only intended to be an
optimization, not a behavior change.  To the extent that it used data
that could not be derived from inventories, it could be argued to be buggy.

I also think that this is a rare case, and worth sacrificing in the name
of a canonical representation.

I think that treating the data in indices as precious is akin to
treating indices as primary data.  And treating indices as primary data
would complicate our model dramatically.  Especially, it would mean that
there could be two contradictory primary sources of ancestry information
in a repository, and this would further complicate the "reconcile" code.

So no, I don't think we should treat this data as precious.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG+uTv0F+nu1YWqI0RAm3RAJwK7cHqyK+qDxMW3S11+GYEGPc2lACfTR7V
xTqUZiCU1G5/MV7nynA4szA=
=rY+l
-----END PGP SIGNATURE-----