Repository growing too large

Hello

We are considering moving our game and engine sources from CVS to SVN,
because it has many nice features, including much more clear branches control.

We stongly want to use SVN for game binaries as well, because of three
features:
  * better handling of binary files, including better storage of deltas in binary files
  * explicit "resolve" command would prevent our artists and designers
    from committing config-files and scripts with conflict markers ;)
  * fast "status" command accessing only local working copy

But we encountered some problems testing SVN usage for version control
of binaries in our games.

We are currently using CVS for binaries of our game project. Its
current size is about 2GB (unversioned), with CVS repository of about 5GB.

We store working revision in CVS, so anyone can checkout it and run
the game.
The lighting for game levels is precalculated from level geometry
(stored in CVS) using global illumination simulation and stored in CVS
as well.
This involves large amounts of data being stored in repository as
levels change and lighting is recomputed. But old revisions of
lighting data are not actually necessary, because we can recalculate
them from level geometry. They are in repository only to support
latest-version checkout and keeping people's working copies
up-to-date, and to allow for quick recovering of most recent revisions
of lighting/level data in case of some trouble.

So, the problem is: we don't need old lighting data revisions, but
they eat a lot of repository space and slow things down. We fighted
this problem in CVS using "cvs admin -o" command to remove old
revisions from repository.

But considering moving to SVN, we found it's hard to discard old
revisions for some specific files, because of SVN's
full-repository-revision ideology.

Could you tell how could we solve this problem with repository growing
too large in SVN?

Some probable solutions:
1. Discard old revisions of specific files from repository using
   repository dump/filter/load. Is it possible?
   It could take a lot of time for 5GB repository, I think.
2. Make some changes to svnadmin or whatever to do the trick. Is this
   feature planned? When could we get it?
   The only problem it causes is when somebody has reference to removed
   revision in his/her working copy, then it's impossible to determine
   whether the file was modified locally or not. But in this case we
   can solve the problem manually (as we do with CVS).
   If latest version is stored in repository as-is, and previous
   versions as deltas from it, discarding old versions for individual
   files won't be too hard. Just discard deltas to make the files look
   like they didn't change.
   Removing the files, erasing them from the repository and re-adding
   them would also work. But collapsing old revisions is much more
   clear way to do it.
3. Use svn:externals to store such files in another repository,
   collapsing their revisions for all that repository at once
   (dump/load).
   But there are several problems with svn:externals, including status
   and commit, and it requires careful pre-design of repositories.

This problem can arise with other binary files as well, so designing
repository with svn:externals BEFORE importing it to SVN won't work.
Textures and levels can also grow too large, and executables certainly
will do.
We could backup repository and remove old revisions periodically, but
it will cut revisions of small text files like various configs and scripts.
   
   

-- 
Best regards,
 Cyberdaemon                          mailto:cyberdaemon@rambler.ru
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org