Checksum mismatch while updating expected actual

checksum mismatch while updating expected actual-83checksum mismatch while updating expected actual-54

But this allowed such manipulation as I described above.

Subverion 1.7 stores this stuff in the working copy root only (for externals, it stores it in the root of an external working copy too).

If the repository gets corrupted you shouldn't hyperventilate knowing at least the latest rev of your data is in multiple places.

An adage you'll hear from snotty slashdotters is "if you only have one backup, your data's not that important." and if you believe dire predictions there's no substitute for multiple, geo-redundant backups. In my examples I'm going to use abcd1234 for subversion's expected checksum and 1234abcd for the actual, and to indicate the corrupted file.

The truth is I never bothered to look up what the recommended solution is, because it seems to me that any code repository that can’t guarantee what I get out of it is the same as what I put into it isn’t a versioning system I really want to trust the “recommended” solution of, anyway.

Comments