9

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 Plastic 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!

Brandon
  • 573
  • 4
  • 7
  • 1
    Why not call or email them and ask directly? Presumably, they'd be happy to offer details of their own product, and tips on how to make it work in that use-case. – Phil Miller Jan 27 '11 at 20:58

2 Answers2

5

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.

una-i
  • 66
  • 2
  • 1
    Wow! That makes my problem feel pretty small. Do you mind me asking what database back-end you're using for Plastic (I'm assuming that you're not using the embedded Firebird DB that comes with it)? – Brandon Jan 28 '11 at 04:38
  • 1
    I think what Unai is using is MySQL, but SQL Server would be a great choice too. (Ok, not for Linux :P) – pablo Jan 31 '11 at 22:41
2

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

Firebird won't scale well to that size.

rubarax
  • 158
  • 1
  • 8
  • 1
    Do you have any data to back this up by any chance? I ask because I'm not familiar at all with the Firebird DB, but am pretty familiar with MySQL and SQL Server. I guess considering my "test installation" is running on Windows Server 2008, it would probably be best to just keep going with Microsoft stack (SQL Server 2008), but was really looking for some hard evidence from a third party. Appreciate the info though - definitely worth looking further into different DBs. – Brandon Jan 28 '11 at 20:23
  • Plastic SCM is tested under really heavy load using a small cluster with 100 client machines working against one single server. There we can tell how the different backends compare (in fact we should publish again one of our shootouts!)... and SQL Server and MySQL simply scale much, much better than Fb. – pablo Jan 31 '11 at 22:42
  • @pablo Now that 4.1 is out how does PostgreSQL compare in your tests? – Kuberchaun May 08 '12 at 18:24
  • Hey! We do support it but we didn't conduct any extensive testing on it. Although I'd love to! :) Why don't you suggest it at plasticscm.uservoice.com ?? – pablo Jun 13 '12 at 14:13