[MERGE] Reconcile can fix bad parent references

[Aaron Bentley]

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

Robert Collins wrote:
> I'm certainly a lot happier. I still don't get why we need
> RevisionParentsProvider though.

We need it because it uses the most reliable source of data

In your last email, you said:

> Thats fair enough. I'm concerned about performance/memory I guess.

I answered those concerns.

> If we
> are accessing the real revisions earlier in the process it seems to me
> that we should have the parent details cached - and the revision index
> is such a cache.

As is the RevisionParentsProvider.

> Reconcile does not check for parents because we don't know of any way
> they can be wrong in a knit format repository today.

Then it is correct to not rely on the knit parents.

> If we can have bad parents from the revision knit

Well, since we don't check, we must assume they are corrupt.

> then we have to check
> that.

Sure.  But *I* don't have to check it as part of *my* change.

> And if we check it first then we know its accurate by the time we
> come to check the file texts ancestry.

Which makes us susceptible to bugs if the code is ever re-ordered.

> So I don't see *why* we ever need
> a different parents provider to the repositories native index in
> find_bad_ancestry.

We need it because your vision of what check and reconcile should
ultimately do has not been achieved.  As it stands, the knit data is not
trusted, the revision data is trusted, and I'm not interested in adding
more check and reconcile stages, just to get *this one* merged.

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

iD8DBQFG20v80F+nu1YWqI0RAgN4AJ9w9cYfo9uHXgtOIP4+PKNGpQLsSACcDtcn
GEBzQW3b+f5yQSLngvbU0ug=
=23hQ
-----END PGP SIGNATURE-----