Molto grandi repository con Plastic SCM

Question

Stiamo indagando SCM plastica come possibile alternativa a Subversion per il controllo di versione con i nostri prodotti. Abbiamo un numero molto elevato di attività binari (principalmente masse d'arte, ma include anche alcuni documenti, AVI, ecc) oltre ad una grande base di codice sorgente. Giusto per mettere un numero su di esso - un checkout svn della nostra testa revisione del ramo tronco prende un po 'più di un'ora e ha una dimensione su disco di circa 9 GB.

Qualcuno ha qualche esperienza con Plastic SCM in un ambiente del genere, o mi può fare riferimento ad alcune white paper o casi di studio in materia di prestazioni di plastica SCM e la gestione di grandi repository? Googling non ha davvero girato molto in termini di ricerca obiettiva - roba da poco pubblicato da Codice stessi. Mi rendo anche conto che Perforce fa molto bene in questo ambiente - ho usato prima - ma siamo una bella piccola squadra, con un altrettanto piccolo budget, e Codice offre questo sistema libero per i piccoli team ( "Community Edition").

Sono molto vicino a quasi l'installazione su un server di test e provarlo ... ma ha voluto inviare la domanda in primo luogo, in modo da non sprecare il mio tempo se qualcun altro ha già provato in un ambiente del genere. Grazie in anticipo per il vostro tempo.

UPDATE 02-FEB-2011: Solo un aggiornamento nel caso qualcuno altro ha una domanda simile e sta visualizzando questo ... Ho avuto plastica installato su una bella macchina modesta Server Windows 2008 (2.8GHz core 2 Duo, 4 GB di RAM, repository vengono archiviati su una SAN in rete locale) che esegue SQL Server 2008 R2 per i repository di plastica. L'importazione della storia subversion revisione ha avuto un po '- poco meno di tre giorni - ~ 28000 revisioni. Tuttavia, è Smokin ' veloce per fare un checkout fresco di un nuovo ramo di plastica - poco meno di 4 minuti con plastica rispetto a più di un'ora su Subversion come sopra descritto . Siamo molto impressionato fino ad ora!

Answer 1

Siamo noi stessi passando da Perforce alla plastica e la nostra repository è di circa 360GB, in modo abbastanza grande anche. E 'in realtà ha funzionato perfettamente anche con file di grandi dimensioni.

Dal momento che siamo nel settore dei videogiochi, file di grandi dimensioni sono un must, e come di conoscere tutte le altre DVCS (Hg, Git) hanno problemi di gestirli.

Answer 2

Per grandi repository le opzioni migliori sono MySQL o SQL Server.

Firebird non scala bene a tale dimensione.