versiones versionador tutorial tortoise subversion repositorio español control conectar svn git version-control mercurial cvs

versionador - tutorial svn



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

  1. para svn "modo de archivo plano", lo que significa FSFS presumo:

    • asegúrese de que está ejecutando la última svn. Se agregaron fragmentos de FSFS en ~ 1.5 IIRC, lo que supondrá una diferencia entre la noche y el día en 500k archivos. El sistema de archivos particular que ejecute 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, ya que tiene que hacer estadísticas en los archivos .svn / así como en los archivos reales.

  2. git tiene un rendimiento mucho mejor que svn, y te debes a ti mismo al menos comparar

Usamos SVN para nuestro control de revisión de código fuente y estamos experimentando usándolo para archivos que no son de código fuente.

Estamos trabajando con un gran conjunto (300-500k) de archivos de texto cortos (1-4kB) que se actualizarán regularmente y es necesario que la versión lo controle. Intentamos usar SVN en modo de archivo plano y estamos teniendo problemas para manejar el primer envío (500k archivos registrados) en aproximadamente 36 horas.

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

Mis preguntas:

  1. Es SVN la solución correcta para mi propósito. La velocidad inicial parece demasiado lenta para el uso práctico.
  2. En caso afirmativo, ¿existe alguna implementación de servidor svn que sea rápida? (Actualmente estamos utilizando el servidor svn predeterminado de gnu / linux y el cliente de línea de comandos).
  3. Si la respuesta es No, ¿cuáles son las mejores alternativas f / oss / comerciales?

Gracias

Edición 1 : necesito control de versión porque varias personas modificarán simultáneamente los mismos archivos y ejecutarán conflictos de diferencias / resolver / resolver 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 controlar su trabajo y verificar el trabajo de otros. 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 un código fuente.

Actualización 1 : Resulta que el problema principal era más un problema del sistema de archivos que un problema de SVN. Para SVN, la confirmación de un solo directorio con medio millón de archivos nuevos no terminó incluso después de 24 horas. Dividir lo mismo en 500 carpetas organizadas en un árbol de 1x5x10x10 con 1000 archivos por carpeta resultó en un tiempo de compromiso de 70 minutos. Compromete las caídas de velocidad significativamente con el tiempo para una sola carpeta con una gran cantidad de archivos. Git parece mucho más rápido. Se actualizará con los tiempos.

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

SVN es bastante malo al cometer un gran número de archivos (especialmente en Windows) ya que todos esos directorios .svn están escritos para actualizar un bloqueo cuando operas en el sistema. Si tiene un pequeño número de directorios, no lo notará, pero el tiempo empleado parece aumentar exponencialmente.

Sin embargo, una vez comprometido (en partes, directorio por directorio quizás) las cosas se vuelven mucho más rápidas. Las actualizaciones no tardan tanto, y puede usar la función de pago disperso (muy recomendable) para trabajar en las secciones del repositorio. Suponiendo que no necesita modificar miles de archivos, encontrará que funciona bastante bien.

Cometer 10.000 archivos: una vez más, todo a la vez no va a ser rápido, pero 1.000 archivos diez veces al día serán mucho más manejables.

Así que inténtelo una vez que tenga todos los archivos allí, y vea 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).

¿Hay alguna razón por la que necesite cometer 10k archivos modificados por confirmación? Subversion se escalaría mucho mejor si cada usuario comprueba su propio archivo de inmediato. Entonces, esa vez al día necesita ''publicar'' los archivos, puede etiquetarlos muy rápido y ejecutar la versión publicada desde la etiqueta

¿Realmente necesitas un sistema de archivos con instantáneas baratas, como ZFS? Puede configurarlo para guardar el estado del sistema de archivos cada 5 minutos y disponer de algún nivel de historial de cambios.

Git es tu mejor apuesta. Puede verificar un sistema operativo completo (dos gigabytes de código en unos pocos cientos de miles de archivos) y seguirá siendo utilizable, aunque el registro inicial tomará bastante tiempo, aproximadamente 40 minutos.

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

bzr también ha hecho grandes avances en la usabilidad.

para tales archivos cortos, verificaría el uso de una base de datos en lugar de un sistema de archivos.