Très grands dépôts de plastique SCM

Question

Nous enquêtons SCM en plastique comme alternative possible à Subversion pour le contrôle de version avec nos produits. Nous avons un très grand nombre d'actifs binaires (principalement des actifs d'art, mais comprend également une documentation, avis, etc.) en plus d'une base de code source très importante. Juste pour mettre un numéro - un svn checkout de notre révision HEAD de la branche du tronc prend un peu plus d'une heure et a une taille sur le disque de 9 Go ~.

Quelqu'un at-il une expérience avec Plastic SCM dans un tel environnement, ou peut me référer à des articles de fond ou des études de cas sur la question de la performance de Plastic SCM et la manipulation des grands dépôts? Googler n'a pas vraiment tourné beaucoup de la manière de la recherche objective - juste des trucs publiés par Codice eux-mêmes. Je me rends compte aussi que Perforce fait très bien dans cet environnement - je l'ai utilisé avant - mais nous sommes une équipe assez petite, avec un budget tout aussi petit, et Codice offre ce système gratuit pour les petites équipes ( « Community Edition »).

Je suis très proche de simplement l'installer sur un serveur de test et l'essayer ... mais je voulais d'abord poster la question, afin de ne pas perdre mon temps si quelqu'un d'autre a déjà essayé dans un tel environnement. Merci d'avance pour votre temps.

Mise à jour 02-FEB-2011: Juste une mise à jour au cas où quelqu'un d'autre a une question similaire et regardent cet ... je suis arrivé en plastique installé sur une machine Windows 2008 Server assez modeste (2.8GHz core 2 Duo, 4 Go de RAM, les dépôts étant stockés sur un réseau SAN sur le réseau local) exécutant SQL Server 2008 R2 pour les dépôts en plastique. L'importation de l'histoire de la révision de la subversion a pris un certain temps - un peu moins de trois jours - ~ 28000 révisions. Cependant, il est Smokin ' rapide à faire une caisse fraîche d'une nouvelle branche de plastique - un peu moins de 4 minutes avec du plastique par rapport à plus d'une heure sur Subversion comme décrit ci-dessus . Nous sommes très impressionné à ce jour!

Answer 1

Nous nous passons de Perforce Plastic et notre référentiel est sur le 360Gb, donc assez grand aussi. Il a travaillé en fait de façon transparente, même en utilisant des fichiers volumineux.

Puisque nous sommes dans l'industrie du jeu vidéo, des fichiers volumineux sont un must, et comme vous connaissez tous les autres DVCS (Hg, Git) ont des problèmes de les manipuler.

Answer 2

Pour les grands référentiels les meilleures options sont MySQL ou SQL Server.

Firebird ne sera pas l'échelle bien à cette taille.