Thomas Lord <[EMAIL PROTECTED]> writes: > In some situations, a corrupt revision library is a serious clue to a > larger problem: perhaps a disk has gone south in some unexpected way; > perhaps an intrusion has taken place. In these cases, the bogus revlib > revision is a forensic clue and automagically removing it amounts to > "collusion to destroy evidence".
There's at least one case where revlibs inode signature occur: backup/restore. In this case, tla and baz will consider your revlib (and your pristine trees as well) as corrupted, and will roughly cease to work untill you manually "rm -fr" this revision. I have a cron job using tla running on the SourceForge compilation farm. This cron job breaks each time there is an important upgrade of the servers (and since their email notification seems broken, it's a silent failure for me). I didn't find a satisfying solution to this problem, but at least in my precise case, automatically removing the revlib entries for which inode signature fails would have been a solution (a better solution for this would have been a second signature, based on a hash, that would survive backup/restore and rebuild the inode signature on demand). > I think you are are dangerously close to the trap that a certain subset > of Canonical's awful hacking fell into: When will you stop talking about Canonical each time you feel something is wrong? -- Matthieu _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
