On Nov 24, 2009, at 7:25 AM, B. Smith-Mannschott wrote:
> On Tue, Nov 24, 2009 at 14:01, Buchbauer Thomas
> <Thomas.Buchbauer_at_ams-engineering.com> wrote:
>> As I know, subversion uses delta-storing in the repository.
>> We would like to use subversion in our product to store very important
>> If such a file would be defect, the arising cost would be dramatically.
>> So I am afraid of, a checked-out file could be different to the
>> checked-in version. Can you exclude this for sure, or is there a little
>> likeliness for such errors (because of the delta-storing algorithm)?
> Subversion is generally *very* good about storing the bytes it's given
> as is. (One consequence of this design decision is the inability to
> alter commits in server-side hook scripts that people periodically
> complain about.)
> Naturally any use of svn:eol-style or svn:keywords on the files in
> question is out of the question when you want to be *certain* the file
> in question will emerge from the repository with content identical to
> when they were last comitted.
> If you're really paranoid, maybe you might look at something like git
> or mercurial, which use a cryptographic hash (SHA1) of the content to
> identify the file's content in the repository. (Any corruption of said
> content is thus *sure* to be noticed).
Subversion uses md5 (and since 1.6, sha1 as well) to verify the integrity of repository contents. While md5 may not be cryptographically secure and thus not protect against byzantine events, it does a great job of content verification. If you are concerned about somebody intentionally changing the contents of your repository, you've got bigger problems.
[ Oh, and since this is about using Subversion and not developing it, this discussion should happen on the users@ list. Thanks. ]
Please start new threads on the <dev_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe_at_subversion.apache.org>.
Received on 2009-11-24 14:35:44 CET