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
> (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
> 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: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Nov 25 01:17:09 2004