[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

AW: Guarantee of subversion's storing / diffing technique

From: Buchbauer Thomas <Thomas.Buchbauer_at_ams-engineering.com>
Date: Wed, 25 Nov 2009 08:19:12 +0100

Hi

Thanks for your answers.

I am not afraid of that somebody intentionally changes the contents of our repository. This aspect I am not interested in.

What I mean is, if it is possible, that a checked-out file is different to the checked-in file (of course, without using an svn keywords, which can cause such effect).
Just because of the delta storing mechanism. (A checked-in file is not stored completly, but only the changes to previous revisions.) I don't know how the mechanism works.
Theoretic: 100% safe would be, if not deltas would be stored, but for each revision the complete file. (Of course, this would be a problem for hd-allocation.)

Regards,
Thomas

-----Ursprüngliche Nachricht-----
Von: Hyrum K. Wright [mailto:hyrum_wright_at_mail.utexas.edu]
Gesendet: Dienstag, 24. November 2009 14:35
An: B. Smith-Mannschott
Cc: Buchbauer Thomas; dev_at_subversion.tigris.org
Betreff: Re: Guarantee of subversion's storing / diffing technique

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:
>> Hi
>>
>> As I know, subversion uses delta-storing in the repository. We would
>> like to use subversion in our product to store very important
>> process-files. 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. ]

-Hyrum

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2424089

Please start new threads on the <users_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe_at_subversion.apache.org>.
Received on 2009-11-25 08:20:57 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.