Sistema de control de versiones escalable (medio millón de files)

Usamos SVN para nuestro control de revisión de código fuente y estamos experimentando su uso para files que no son de código fuente.

Estamos trabajando con un set grande (300-500k) de files de text cortos (1-4kB) que se actualizarán regularmente y necesitan controlar la versión. Intentamos usar SVN en modo de file plano y se está luchando para manejar la primera confirmación (500k files registrados), lo que lleva aproximadamente 36 horas.

Diariamente, necesitamos que el sistema pueda manejar 10k files modificados por transacción de compromiso en poco time (<5 min).

Mis preguntas:

  1. SVN es la solución adecuada para mi propósito. La velocidad inicial parece demasiado lenta para el uso práctico.
  2. En caso afirmativo, ¿hay una implementación de server svn particular que sea rápida? (Actualmente estamos utilizando el server svn pnetworkingeterminado de gnu / linux y el cliente de la command-line).
  3. Si no, ¿cuáles son las mejores alternativas f / oss / comerciales?

Gracias


Edición 1 : Necesito control de versión porque varias personas estarán modificando simultáneamente los mismos files y harán conflictos manuales de diferencia / fusión / resolución de la misma manera que los progtwigdores editan el código fuente. Por lo tanto, necesito un repository central en el que las personas puedan verificar su trabajo y verificar el trabajo de los demás. El flujo de trabajo es prácticamente idéntico a un flujo de trabajo de progtwigción, excepto que los usuarios no son progtwigdores y el contenido del file no es el código fuente.


Actualización 1 : Resulta que el problema principal era más un problema del sistema de files que un problema SVN. Para SVN, la comisión de un solo directory con medio millón de files nuevos no terminó incluso después de 24 horas. La split de la misma en 500 carpetas dispuestas en un tree de 1x5x10x10 con 1000 files por carpeta dio como resultado un time de compromiso de 70 minutos. La velocidad de confirmación disminuye significativamente con el time para una sola carpeta con gran cantidad de files. Git parece mucho más rápido. Se actualizará con los times.

es SVN adecuado? Mientras no esté revisando o actualizando todo el repository, entonces sí lo está.

SVN es bastante malo al comprometer un gran número de files (especialmente en Windows) ya que todos esos directorys .svn se escriben para actualizar un locking cuando se opera en el sistema. Si tiene una pequeña cantidad de directorys, no lo notará, pero el time empleado parece boost exponencialmente.

Sin embargo, una vez confirmado (en fragments, directory por directory), las cosas se vuelven mucho más rápidas. Las actualizaciones no demoran tanto y puede usar la function de extracción dispersa (muy recomendada) para trabajar en secciones del repository. Suponiendo que no necesita modificar miles de files, encontrará que funciona bastante bien.

Comprometer 10,000 files, de nuevo, todos a la vez no serán rápidos, pero 1000 files diez veces al día serán mucho más manejables.

Así que pruébelo una vez que tenga todos los files y vea cómo funciona. Todo esto se solucionará en 1.7, ya que el mecanismo de copy de trabajo se modifica para eliminar esos directorys .svn (por lo que mantener los lockings es más simple y mucho más rápido).

A partir de julio de 2008, el repo de Linux git repo tenía aproximadamente 260,000 files. (2.6.26)

http://linuxator.wordpress.com/2008/07/22/5-things-you-didnt-know-about-linux-kernel-code-metrics/

En esa cantidad de files, los desarrolladores del kernel todavía dicen que git es realmente rápido. No veo por qué sería más lento en 500,000 files. Git rastrea el contenido, no los files.

para esos files cortos, verificaría el uso de una database en lugar de un sistema de files.

git es tu mejor apuesta. Puede comprobar en un sistema operativo completo (dos gigabytes de código en unos pocos cientos de miles de files) y sigue siendo utilizable, aunque la verificación inicial llevará bastante time, como unos 40 minutos.

  1. para svn "modo de file plano", lo que significa FSFS supongo:

    • asegúrese de ejecutar el último svn. FSFS agregó sharding en ~ 1.5 IIRC, que será una diferencia día / noche en 500k files. El sistema de files particular que ejecuta también tendrá un gran efecto. (Ni siquiera pienses en esto en NTFS.)
    • Vas a estar vinculado a IO con tantas transactions de files. SVN no es muy eficiente con esto, tiene que registrar files en .svn / así como en los files reales.
  2. git tiene mucho mejor performance que svn, y te debes a ti mismo por lo less comparar

Recomiendo Mercurial, ya que todavía lidera git en el departamento de usabilidad (git ha estado mejorando, pero, eh).

bzr también ha avanzado en usabilidad.

¿Realmente necesita un sistema de files con instantáneas económicas, como ZFS? Puede configurarlo para save el estado del sistema de files cada 5 minutos para aprovechar algún nivel de historial de cambios.

¿Hay alguna razón por la que deba enviar 10k files modificados por confirmación? Subversion escalaría mucho mejor si cada usuario verifica en su propio file de inmediato. Entonces, una vez al día, necesitas 'publicar' los files, puedes labelrlos muy rápido y ejecutar la versión publicada desde la label