Mutating history in Subversion and Bazaar
David Allouche
david at allouche.net
Tue Sep 5 15:12:12 BST 2006
Aaron Bentley wrote:
> John Arbash Meinel wrote:
>>> Unfortunately we don't. We check the sha-1 sums when we extract
>>> the texts, but to check them at 'join()' time means that we have
>>> to extract the content, apply it to the previous text in the case
>>> it is a delta, which may mean extracting all of the other
>>> previous texts, etc.
>
> Yes. I suggested we check the parent sha-1's because it's cheaper to
> do that. It provides a good guarantee against history mutation, but
> it doesn't provide a good guarantee against broken knit deltas.
What Aaron says.
I think that would be a sufficiently useful safeguard against the sort
of history mutation problems you find in all reproducible import
systems, like the foreign-vcs plugins.
Can we get that implemented before 1.0? Please?
> Yes, that sounds like a possible improvement, if the overhead isn't
> too big.
That's a bit over my head, but that all sounds reasonable.
However I think we should rather focus on having a good enough routine
check with the minimal performance impact. If bzr turns out measurably
slower than other systems, it does not help to claim being much more
robust and cautious with data integrity, because that's not something
people can measure.
Then of course, have a full-fledged data integrity test. Does "bzr
check" already cover the sort of corruption you are talking of here?
To check for history mutation, we also need to be able to check multiple
repositories for agreement, in addition to internal consistency. Maybe
the UI for that could be "bzr check [branch] ..." (note the ellipsis).
Can that be a 1.0 goal too?
--
-- ddaa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060905/6cd0ccb8/attachment.pgp
More information about the bazaar
mailing list