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
* 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 lighting for game levels is precalculated from level geometry
(stored in CVS) using global illumination simulation and stored in CVS
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
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
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
We could backup repository and remove old revisions periodically, but
it will cut revisions of small text files like various configs and scripts.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Sep 1 01:00:21 2004