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

Re: Storing large amounts of medium-sized binary files in Subversion

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Wed, 11 Aug 2010 00:08:52 -0400

On Tue, Aug 10, 2010 at 7:07 PM, David Weintraub <qazwart_at_gmail.com> wrote:
> On Mon, Aug 9, 2010 at 1:04 PM, Andreas Kotes <count-linux_at_flatline.de> wrote:
>> Hello,
>>
>> how good/bad an idea is storing large amounts of medium-sized files
>> (think Yum/RPM repositories with full CentOS/EPEL releases) in
>> SVN for rollback and other purposes?
>
> The big problem with Subversion is that you cannot (easily) remove
> information once it is in the repository. Yes, I know that binaries
> are stored in delta format, but each revision takes up a ton of room
> anyway.
>
> I found it better to use a release manager for storing releases. We
> used Nexus (which is really for Maven, but you can use it for other
> purposes). This way, we can easily remove obsolete revisions and use
> the web interface to search and download releases we need.

I find git's gpg signatures for tags to be pretty handy for binary
releases, and you can store development branches as parts of
development environments with no need to submit upstream. It helps
keep your central repository considerably lighter if you can store
your development changes locally, and only submit them when you think
they're sane enough.

It does take a different release model, and sometimes developers have
a tendency to hare off in very strange directorions with local
"trunks".
Received on 2010-08-11 06:09:32 CEST

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.