Repositorios muy grandes con Plastic SCM

Question

Estamos investigando Plastic SCM como posible alternativa a Subversion para el control de versiones con nuestros productos. Tenemos una gran cantidad de activos binarios (principalmente activos artísticos, pero también incluye cierta documentación, AVI, etc.) además de una gran base de código fuente. Solo para poner un número en él: una comprobación de svn de nuestra revisión HEAD de la rama del tronco tarda algo más de una hora y tiene un tamaño en el disco de ~ 9 GB.

¿Alguien tiene alguna experiencia con Plastic SCM en un entorno de este tipo, o puede remitirme a algunos documentos técnicos o estudios de casos sobre el rendimiento de Plastic SCM y el manejo de grandes repositorios? Google no ha cambiado mucho en el camino de la investigación objetiva, solo material publicado por Codice. También me doy cuenta de que Perforce lo hace muy bien en este entorno, lo he usado antes, pero somos un equipo bastante pequeño, con un presupuesto igualmente pequeño, y Codice ofrece este sistema gratis para equipos pequeños ("Edición de la Comunidad").

Estoy a punto de instalarlo en un servidor de prueba y probarlo ... pero quería publicar la pregunta primero, para no perder el tiempo si alguien más ya lo había probado en un entorno como este . Gracias de antemano por tu tiempo.

ACTUALIZACIÓN 02-FEB-2011: Apenas una actualización en caso de que alguien más tiene una pregunta similar y está viendo esto ... Tengo instalado plástico en una máquina bastante modesto servidor Windows 2008 (2,8 GHz Core 2 Duo, 4 GB de RAM, repositorios que se almacenan en una SAN en la red local) que ejecutan SQL Server 2008 R2 para los depósitos de plástico. La importación del historial de revisión de subversión llevó un tiempo, poco menos de tres días, ~ 28000 revisiones. Sin embargo, es SMOKIN ' rápido para hacer una nueva extracción de una nueva rama de plástico: apenas 4 minutos con plástico en comparación con más de una hora en Subversion como se describe anteriormente. Estamos muy impresionado hasta el momento!

Answer 1

Nos estamos moviendo de Perforce a Plastic y nuestro repositorio tiene aproximadamente 360Gb, así que es bastante grande también. En realidad funcionó a la perfección incluso con archivos ENORMES.

Dado que estamos en la industria de los videojuegos, los archivos de gran tamaño son obligatorios, y como , usted sabe que todos los demás DVCS (Hg, Git) tienen problemas para manejarlos.

Answer 2

Para repositorios grandes, las mejores opciones son MySQL o SQL Server.

Firebird no se adaptará bien a ese tamaño.