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

Usamos SVN para nuestro control de revisión de código fuente y estamos experimentando su uso para archivos que no son de código fuente.Sistema de control de versiones escalable (medio millón de archivos)

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

Diariamente, necesitamos que el sistema pueda manejar 10k archivos modificados por transacción de compromiso en un tiempo corto (< 5 min).

Mis preguntas:

Es SVN la solución adecuada para mi propósito. La velocidad inicial parece demasiado lenta para el uso práctico.
En caso afirmativo, ¿hay una implementación de servidor svn particular que sea rápida? (Estamos usando actualmente el servidor SVN por defecto GNU/Linux y el cliente de línea de comandos.)
En caso negativo, ¿cuáles son los mejores// alternativas comerciales OSS f

Gracias

Editar 1: Necesito control de versiones porque varias personas estarán modificando simultáneamente los mismos archivos y estarán haciendo diff/merge/resolve-conflicts manualmente de la misma manera que los programadores editan el código fuente. Por lo tanto, necesito un repositorio 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 programación, excepto que los usuarios no son programadores y el contenido del archivo no es el código fuente.

Actualización 1: Resulta que el principal problema era más una cuestión de sistema de archivos que una cuestión de subversion. Para SVN, la confirmación de un único directorio con medio millón de archivos nuevos no finalizó incluso después de 24 horas. La división de la misma en 500 carpetas dispuestas en un árbol de 1x5x10x10 con 1000 archivos por carpeta dio como resultado un tiempo de compromiso de 70 minutos. La velocidad de confirmación disminuye significativamente con el tiempo para una sola carpeta con gran cantidad de archivos. Git parece mucho más rápido. Se actualizará con los tiempos.

Fuente

2010-03-31 hashable

Si está haciendo lo que creo que está haciendo, buscaría algún tipo de CMS. – erikkallen

Como otros señalaron: podría valer la pena explicar lo que está tratando de resolver en general, ya que un sistema de control de versiones * puede * ser la solución incorrecta (al menos no la más eficiente) para su problema. – paprika

O lo que dijo erikkallen arriba, o un sistema de archivos con soporte integrado de instantáneas. Más detalles sobre el problema serían buenos para determinar si el control de la versión es la solución correcta para el problema. – Juliano

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

SVN es bastante malo al comprometer un gran número de archivos (especialmente en Windows) ya que todos los directorios .svn se escriben para actualizar un bloqueo cuando se opera en el sistema. Si tiene una pequeña cantidad de directorios, no lo notará, pero el tiempo empleado parece aumentar exponencialmente.

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

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

Así que pruébalo una vez que tengas todos los archivos y comprueba cómo funciona. Todo esto se solucionará en 1.7, ya que el mecanismo de copia de trabajo se modifica para eliminar esos directorios .svn (por lo que mantener los bloqueos es más simple y mucho más rápido).

Fuente

2010-03-31 20:08:46 gbjbaanb

No es realmente la gran cantidad de archivos, sino la gran cantidad de directorios que más impacta en el rendimiento. –

@gbjbaanb @Sander Demasiados archivos en una sola carpeta parece ser el problema. Mire la Actualización 1. – hashable

Me estaba refiriendo a las ralentizaciones descritas por @gbjbaanb causadas por los directorios .svn. Esa ralentización es causada por tener muchos directorios, no por tener muchos archivos. Incluso bloquear la copia de trabajo antes de la operación y desbloquearla luego toma mucho tiempo si hay muchos directorios. –

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

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

En ese número de archivos, los desarrolladores del núcleo todavía dicen Git es muy rápido. No veo por qué sería más lento en 500,000 archivos. Git rastrea el contenido, no los archivos.

Fuente

2010-03-31 18:07:57 jonescb

Para reafirmar esto: Acabo de probar un compromiso que básicamente reescribió todos los contenidos de un enorme repositorio (26000 archivos, 5 GB). Tardó unos 6 minutos, la mayoría de E/S limitada en un montaje de red no tan rápido. En su caso de uso, los difs son más como 50MB, por lo que debería ver tiempos de compromiso mucho más rápidos. (Su confirmación inicial aún podría demorar un tiempo, supongo que de cinco minutos a una hora, dependiendo de su sistema). – Cascabel

Tenga cuidado. Git tiene una curva de aprendizaje empinada para programadores y puede ser desconcertante para los no codificadores. Ahora uso git todo el tiempo y no podría trabajar sin él, pero tardé unos meses en ponerme cómodo. Asegúrate de estar listo para dedicar algunas horas a entrenar a tus colegas no programadores si te comprometes con Git-- sin juego de palabras :) – AndyL

@Andy Gracias por ese valioso comentario sobre la curva de aprendizaje de Git. – hashable

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

Fuente

2010-03-31 18:09:04

a solo 40 mins? ¡Guauu! –

Suponiendo que el sistema tiene disco rápido, sí. Supongo que SSD sería el camino a seguir para obtener la máxima velocidad de los sistemas de control de revisiones. –

Gracias por ese consejo. Sí. Usar un SSD como servidor de SVN HDD aceleraría las cosas. – hashable

de SVN "modo de archivo plano", que significa FSFS presumo:
- asegurarse de que está ejecutando la última SVN. FSFS agregó sharding en ~ 1.5 IIRC, que será una diferencia día/noche en 500k archivos.El sistema de archivos particular que ejecuta también tendrá un gran efecto. (Ni siquiera pienses en esto en NTFS.)
- Vas a estar vinculado a IO con tantas transacciones de archivos. SVN no es muy eficiente con esto, tiene que registrar archivos en .svn/así como en los archivos reales.
Git tiene un mejor rendimiento que forma SVN, y se lo debes a ti mismo para al menos comparar

Fuente

2010-03-31 18:13:26

@Nathan Sí. Creo que estamos usando la versión 1.6.x de SVN. – hashable

y con el número de archivos, svn 1.7 tendrá un soporte mucho mejor descartando los directorios .svn que tienen un impacto significativo con una gran cantidad de archivos. Por supuesto, esto no ha salido aún. – gbjbaanb

sharding le ayudará cuando tenga una gran cantidad de revisiones, no mejora nada para la cantidad de archivos. Son las revisiones fragmentadas en el repositorio. –

lo que realmente necesita un sistema de archivos con instantáneas baratas, como ZFS? Puede configurarlo para guardar el estado del sistema de archivos cada 5 minutos para aprovechar algún nivel de historial de cambios.

Fuente

2010-03-31 18:21:32 joeforker

Su respuesta parece una pregunta (¿error ortográfico?). De todos modos, buen puntero! – paprika

Se llama método socrático ;-) – joeforker

para esos archivos cortos, me gustaría consultar sobre el uso de una base de datos en lugar de un sistema de archivos.

Fuente

2010-03-31 18:39:54 Javier

¿Hay algún motivo por el que deba enviar 10k archivos modificados por confirmación? Subversion escalaría mucho mejor si cada usuario verifica en su propio archivo de inmediato. Entonces esa vez una vez al día necesita 'publicar' los archivos, puede etiquetarlos muy rápido y ejecutar la versión publicada de la etiqueta

Fuente

2010-04-01 18:09:34

@Sander 10k es el límite superior. Un usuario no puede registrar solo un archivo a la vez debido a dependencias entre archivos. – hashable

¿Quiere decir que al hacer su trabajo manualmente, producen hasta 10k archivos que necesitan ser un compromiso? Eso suena bastante imposible a menos que se generen los archivos, en cuyo caso generalmente es mejor almacenar los archivos fuente en control de fuente. –

El trabajo manual no se realiza a nivel de archivo. Pequeñas ediciones (a la información representada colectivamente en todos los archivos) pueden provocar la modificación de varios archivos. Sí. para el caso de límite superior de 10000 modificaciones de archivo, los cambios probablemente se deban a la modificación del archivo programático. (Hay una edición tanto humana como automática de los archivos). – hashable

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

bzr también ha avanzado mucho en usabilidad.

Fuente

2010-04-01 22:18:54

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

Respuesta

Cuestiones relacionadas