On 11/17/2009 11:23 PM, Pat Farrell wrote:
> I suggest that the svn developers consider strongly warning people that
> using it for big binary things is not optimal. It works well for source
> code, and at least "OK" for small binary things (couple of pages of Word
> or OpenOffice documents). But when the files get into hundreds of
> megabytes, for each revision, I think SVN is not the right tool.
We wouldn't use SVN at our company if it couldn't handle situations like
that. The ability to shove a few hundred MB binary file into SVN, and
have it be efficient over the wire is a big benefit. It's rare that I
want to version something that big, but it's happened. More common for
us are 10-50MB files which need to be versioned.
Then there's the use-case where you use FSVS as a front-end to an SVN
repository to version control an entire Linux/Unix server. Or at least,
as much of the file system as it makes sense to version. Some of the
initial commits are revisions of a few hundred MB with thousands of
files in a single commit. This is hugely useful for me when I wear my
sysadmin hat because I know that changes are tracked and that I can
easily go back and examine changes.
What would be useful would be the ability, on a repository by repository
basis to have optional repository properties that could implement a
restriction. Of course, you can probably already do that today with a
hook script.
If the obliterate command makes it in, I really want it to be a property
that gets set on the repository that has to be enabled in order to
obliterate anything at all. Lack of an obliterate command means that
it's a lot harder for an attacker to remove something from the
repository and have it go unnoticed. (They'd have to do a
dump/filter/load, which takes a while.)
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2419315
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-11-18 06:30:18 CET