Sehr große Repositories mit Plastik -SCM

Question

Wir untersuchen Plastic SCM als mögliche Alternative zur Subversion für die Versionskontrolle mit unseren Produkten. Wir haben eine sehr große Anzahl von binären Vermögenswerten (hauptsächlich Kunstvermögen, aber auch einige Dokumentationen, AVIS usw.) zusätzlich zu einer sehr großen Quellcode -Basis. Nur um eine Nummer darauf zu setzen - eine SVN -Checkout unserer Kopfrevision der Kofferraumzweig dauert etwas mehr als eine Stunde und hat eine Größe auf einer Festplatte von ~ 9 GB.

Hat jemand Erfahrung mit Plastik -SCM in einer solchen Umgebung oder kann mich auf einige Whitepapers oder Fallstudien über die Leistung von Plastik -SCM und den Umgang mit großen Repositorys verweisen? Googeln hat sich nicht wirklich in der objektiven Recherche gedreht - nur Dinge, die von Codice selbst veröffentlicht wurden. Mir ist auch klar, dass Perforce in dieser Umgebung sehr gut abschneidet - ich habe es schon einmal verwendet -, aber wir sind ein ziemlich kleines Team mit einem ebenso kleinen Budget, und Codice bietet dieses System kostenlos für kleine Teams ("Community Edition").

Ich bin sehr nahe daran, es nur auf einem Testserver zu installieren und es auszuprobieren ... aber wollte die Frage zuerst posten, um meine Zeit nicht zu verschwenden, wenn jemand anderes sie bereits in einer solchen Umgebung ausprobiert hat. Vielen Dank im Voraus für Ihre Zeit.

Aktualisieren Sie 02-Feb-2011: Nur ein Update für den Fall, dass jemand anderes eine ähnliche Frage hat und dies anzeigt ... Ich habe Plastik auf einem ziemlich bescheidenen Windows 2008 -Servergerät installiert (2,8 GHz Core 2 Duo, 4 GB RAM, Repositories werden auf einem SAN auf dem Lokal gespeichert Netzwerk) Ausführen von SQL Server 2008 R2 für die Kunststoff -Repositorys. Der Import der Subversion Revision History dauerte eine Weile - knapp drei Tage - ~ 28000 Überarbeitungen. Wie auch immer es ist Rauchen ' Schnell, um einen neuen Zweig von Plastik zu überprüfen - nur 4 Minuten mit Plastik im Vergleich zu einer Stunde bei Subversion wie oben beschrieben. War sehr beeindruckt bis jetzt!

Answer 1

Wir bewegen uns von Perforce zu Plastik und unser Repository ist ungefähr 360 GB, also auch ziemlich groß. Es funktionierte tatsächlich nahtlos mit riesigen Dateien.

Da wir in der Videospielbranche sind, sind große Dateien ein Muss, und wie Sie wissen, haben alle anderen DVCs (HG, GIT) Probleme, die sie behandeln.

Answer 2

Für große Repositories sind MySQL- oder SQL Server die besten Optionen.

Firebird wird nicht gut auf diese Größe skalieren.