Very large repositories with Plastic SCM

We are investigating Plastic SCM as possible alternative to Subversion for version control with our products. We have a very large number of binary assets (mainly art assets, but also includes some documentation, AVIs, etc.) in addition to a very large source code base. Just to put a number on it - a svn checkout of our HEAD revision of the trunk branch takes a little over an hour and has a size on disk of ~9 GB.

Does anyone have any experience with Plastic SCM in such an environment, or can refer me to some whitepapers or case studies on the matter of Plast开发者_开发百科ic SCM's performance and handling of large repositories? Googling hasn't really turned much in the way of objective research - just stuff published by Codice themselves. I also realize that Perforce does extremely well in this environment - I've used it before - but we're a pretty small team, with an equally small budget, and Codice offers this system free for small teams ("Community Edition").

I'm very close to just installing it on a test server and trying it out...but wanted post the question first, so as to not waste my time if someone else has already tried it out in such an environment. Thanks in advance for your time.

UPDATE 02-FEB-2011: Just an update in case anyone else has a similar question and is viewing this...I got Plastic installed on a pretty modest Windows 2008 Server machine (2.8GHz Core 2 Duo, 4 GB RAM, repositories being stored on a SAN on the local network) running SQL Server 2008 R2 for the Plastic repositories. The import of subversion revision history took a while - just under three days - ~28000 revisions. However, it is SMOKIN' fast to do a fresh checkout of a new branch from Plastic - just shy of 4 minutes with Plastic compared to over an hour on Subversion as described above. We're very impressed so far!

We are moving ourselves from Perforce to Plastic and our repository is about 360Gb, so quite large too. It actually worked seamlessly even using HUGE files.

Since we're in the videogame industry, large files are a must, and as you know all the other DVCS (Hg, Git) have issues handling them.

For large repositories the best options are MySQL or SQL Server.

Firebird won't scale well to that size.