[MERGE] Prevent knit corruption by checking parents
John Arbash Meinel
john at arbash-meinel.com
Fri Sep 22 21:25:51 BST 2006
Aaron Bentley wrote:
>>> 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
> Well, okay, but that's pretty expensive to verify, too.
Not really. It doesn't require any file-level operations. Just 1
inventory-level operation. Because all you need to verify the testament
is the inventory and revision objects.
And then at the lower level, since you know the inventory sha1, you can
match them to the actual file sha1 as you copy things in. So when you
want to verify parent sha1 you open up their Revision texts, and just
check the testament_sha1. Of the remote matches the local.
So that means we have to read the sha1 *from the bytes we are copying*,
and extract 1 inventory, and a couple revision xml contents. A lot less
than extracting a parent text for every modified file. (Especially since
we don't otherwise handle the parent information).
>>> 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
I would be curious to know what alternatives you can think of. And I
would be willing to sacrifice performance now, as long as we have a plan
My proposal requires a format bump, since Revision now contains
different information. And if we are doing a format bump, we could
consider including the sha1 in the knit indexes.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060922/caf37199/attachment.pgp
More information about the bazaar