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

Re: Guarantee of subversion's storing / diffing technique

From: B. Smith-Mannschott <bsmith.occs_at_gmail.com>
Date: Tue, 24 Nov 2009 14:25:53 +0100

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).

// Ben


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:26:07 CET

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