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

Re: svn not sutable for large multimedia assets?

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-11-25 01:14:53 CET

I don't believe that subversion can compete with AlienBrain, at least
not yet. AlienBrain is specifically tailored for game companies with
"huge binary files":

On Nov 24, 2004, at 2:19 PM, Dierk Ohlerich wrote:
> (1) Most files are binary. We need file locking. I see this is one of
> your top priorities in the roadmap. (fine)

Working on this right now.

> (2) We need a way of removing old versions from the database. Our
> projects grow with the performance of graphics cards. We will produce
> more than 500 GB worth of history-data next year. Deleting old
> versions is acceptable, while "taping" or "burning" them away is of
> course much better.

We have no way to do this yet, other than dumping/filtering/loading
(which is *not* viable when you have 500GB to sift through).

> (3) It seems that there are many reports that very large repositories
> get slower and slower. If this is a function of the number of
> revisions stored in the repository, we should be save. But if it is a
> function of the size of the database, we have a problem here.

There should be no such bug, either related to the amount of data
stored, nor the number of revisions. What reports say this?

> (4) Subversion stores a hidden, local copy of each file. This is good
> for source-codes, but my working copy of all projects is 50 GB at the
> moment, doubling that would hurt. I also fear that it slows down
> updating the working copy, because of all the disk access. Updating
> all clients after a large batch export is painfully slow.

This is an oft-requested feature, but not on our short or medium-term
roadmap. Probably something that will show up in a 2.0 rewrite of the
working-copy library.

> (5) Some files need no revision control since they are automatically
> generated, or come from an application that does it's own revision
> controlling. The revision control system is misused as an instrument
> of deployment. I don't want to feel guilty of doing a batch export,
> being punished by having to burn 5 CD's for the history backup.

I don't understand this point. Our standard reply is: "stop using the
revision control system as an instrument of deployment." Don't put
everything under revision control, and create yourself a separate
deployment system.

> On the other hand, the differenced data storage and free branching
> would be really nice to have.

Yes, they're very nice. :-)

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 25 01:17:09 2004

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.