[MERGE] Prevent knit corruption by checking parents

[Aaron Bentley]

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

John Arbash Meinel wrote:
>>I understand your caution.  It really disturbs me that using the
>>standard API correctly can allow knits to become corrupt, though.

> I'm not vetoing it. In fact, I think we probably do need something like
> it. 

I'm okay with delaying it to 0.12, which should give us time to do it
right, whatever "right" turns out to be.

> I don't think that 'using the standard API correctly can allow knits
> to become corrupt' is a correct statement, though. The only way it can
> become corrupt is if parents are corrupt (because there is a
> disagreement).

Right.  But that is easy to accomplish.  Nothing stops someone from,
e.g. hacking on baz-import, and "fixing" it, so it produces different
output but the same revision-ids.

> Then that will cascade to all derived texts, up until
> another full cacherev. And it will be detected the next time the texts
> are read. So we do have some safety catches present.

Right.  It's lots better than, say, Arch.  But those detections happen
after your repository is already corrupt.  And the delay makes it hard
to determine the cause of the corruption.

> I think what I would like to see the most, is for revisions to get the
> testament sha1 as part of the revision text. Then you can check that all
> file contents match, just by checking a single sha1. But that is for the
> future.

Well, okay, but that's pretty expensive to verify, too.

> For now, I just want Martin & Robert to decide if the performance impact
> is worth, considering this is a fairly unlikely and rare case of
> corruption. I'm probably about +0.6 myself. But I would rather the
> system be slower and more robust. But I know one of our main complaints
> right now is that we are slow. (Sort of a: users see performance, they
> don't *see* robustness, until it bites them really hard).

There are alternative approaches we can pursue which are messier, but
shouldn't lose as much performance.  Best-case, we can avoid the extra
round-trips, but still do the detection before the records get into our
knit.

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

iD8DBQFFFEN90F+nu1YWqI0RApgKAJ9OYAVKjnd4D+lNbXgWl0qdEpPS3ACfUjZ5
EbvCtZN699Xa+oQq7aVz4AM=
=ysLv
-----END PGP SIGNATURE-----