Mejores prácticas para un solo proyecto SVN grande

Question

He heredado un único proyecto en svn: 30Gb en más de 300 000 archivos. Hay toneladas de archivos binarios allí en su mayoría en una carpeta de imágenes. Operaciones como actualizar todo el proyecto pueden ser dramáticamente lentas.

El equipo ha desarrollado un proceso para ejecutar solo la actualización/activar las carpetas específicas en las que están trabajando y terminar revisando el código roto porque "funciona en mi computadora". La copia de trabajo de una persona puede incluir un código obsoleto, un código cambiado y un código olvidado que nunca se haya confirmado. Además, se produce una ramificación mínima.

Mi solución personal es un pequeño script bash checkout/build a las 5 a.m. todas las mañanas; sin embargo, no todos tienen la valentía de línea de comandos para copiar mi solución y preferirían la comodidad del svn de tortuga y el proceso roto.

¿Alguien ha intentado sintonizar un repositorio tan grande y puede dar consejos? ¿Hay algunas prácticas recomendadas que pueda implementar para trabajar con repositorios grandes en los que pueda facilitar el acceso a todos?

P.S. los externos no parecen ser una buena idea y SVN optimizations to keep large repositories responsive no se aplica aquí porque estoy tratando con un solo proyecto

P.P.S. Esto actualmente se está analizando también: http://www.ibm.com/developerworks/java/library/j-svnbins.html

Answer 1

En primer lugar, actualice a SVN 1.6 tanto en el cliente como en el servidor. Las notas latest release mencionan una aceleración para archivos grandes (r36389).

En segundo lugar, esto puede no ser demasiado apropiado para usted si tiene que tener todo el proyecto en su copia de trabajo, pero use sparse directories. Hacemos esto para nuestro repositorio grande, lo primero que hace un cliente es consultar el directorio de nivel superior solamente, luego para obtener más datos, use el navegador repo para ir al directorio deseado y "actualizar a esta revisión" en él. Funciona maravillosamente en TortoiseSVN. 1.6 también tiene la opción 'Reducir profundidad' para eliminar directorios en los que ya no necesita trabajar.

Si esto no es para usted, puede hacer una actualización de las partes de la copia de trabajo. La actualización tiende a ser lenta cuanto más archivos tienes (en Windows, NTFS parece ser particularmente pobre con la estrategia de bloqueo utilizada para actualizar. Bert Huijben noticed this y sugirió una solución - TBA con la versión 1.7, pero podrías reconstruir tu código actual con su 'solución rápida'

Una alternativa podría ser la de cambiar su sistema de archivos, si se puede cambiar el formato, puede probar con el ext2 IFS driver, pero estoy seguro de que tenga cuidado de que

última opción.! - apague su escáner de virus para .svn firectories, y también para el repositorio en el servidor. Si está ejecutando Apache en el servidor, asegúrese de tener activadas las alertas por un tiempo corto (para evitar que se produzca una nueva autenticación). También desactive la indexación en sus directorios de copia de trabajo y sombra también. (el último no ayuda mucho, pero puede ver una mejora mejor que yo, apagando AV en el servidor aumentó mi respuesta SVN 10 veces).

Answer 2

Para manejar el tamaño difícil de manejar, consideraría dividir los datos binarios en otra rama (o incluso eliminarlos completamente para almacenarlos en otro lugar), separados del código. Esto al menos debería acelerar las cosas, especialmente si los datos no cambian con frecuencia.

Entiendo la necesidad de que las personas tengan una ubicación central para sus herramientas, datos y bibliotecas, pero simplemente no funciona bien tener un volcado.

Answer 3

Yo era un gerente de SCM en una situación similar. Tuvimos un proyecto con más de 200,000 archivos (principalmente código) que tenía algunos de los mismos problemas. Nuestra solución fue dividir el repositorio en dos versiones. Una versión es una versión de desarrollo y la otra es una versión de producción. Sembró la versión de desarrollo con la copia de trabajo más reciente y mejor conocida de todo el código. Los desarrolladores comenzaron con eso e hicieron cambios, check in/out, etc. Una vez que sintieron que las cosas estaban estables, un administrador (en nuestro caso, un administrador de compilación) fusionó el código e hizo una prueba de compilación para verificar que todo funcionara correctamente. Si todo pasó, fue bueno. Si no fuera así, el administrador de la construcción perseguiría al desarrollador y los castigaría severamente. Tuvimos algunos de los mismos problemas al principio donde "funcionó en mi computadora", etc., pero en poco tiempo se resolvieron gracias a golpes y flagelaciones .....

En puntos específicos, el código de desarrollo (TODO EL CÓDIGO DE TRABAJO !!!!) se fusionó de nuevo en la ejecución de producción y se lanzó al cliente.

Answer 4

Tenemos dos repositorios, uno para nuestro código (cambia con frecuencia) y otro para nuestros datos binarios (muy grande, cambia con poca frecuencia). A veces es un dolor, pero vale la pena la mejor velocidad cuando se trabaja con código.

También tenemos una secuencia de comandos de Ruby que llamamos "actualización diaria", registrada en nuestro repositorio, que iniciamos en todas nuestras PC de desarrollo a través de una tarea programada de Windows, cada mañana temprano. Actualiza los registros de la última versión y luego crea todo localmente, por lo que estamos listos para partir tan pronto como lleguemos por la mañana.

Hay algunos inconvenientes que aún no hemos resuelto; por ejemplo, cuando se ejecutan nuestras pruebas automáticas, actualmente existe un desfase entre cuando revisan el código y cuando revisan los datos, por lo tanto, cuando confirmamos cambios en ambos repositorios, el servidor de CI algunas veces obtiene código viejo y datos nuevos, lo que causa fallas de prueba.

Cuando confirmamos cambios en el depósito de datos, solemos informar a todos los demás que necesitan actualizar (todos nos sentamos en la misma sala). De lo contrario, no solemos actualizar los datos manualmente; simplemente dejamos que el script de actualización diaria lo mantenga actualizado.

Answer 5

¿Es posible dividir el proyecto en proyectos más pequeños que se pueden conectar a través de algún tipo de sistema de complemento?

Answer 6

Voy a ser breve:

• de actualización a la última versión (1.6.x). 1.5.x también tenía optimizaciones de velocidad.
• Asegúrese de que todos estén usando la misma versión de TortoiseSVN que está construida con la versión exacta del servidor. Tuvimos muchos problemas con chicos actualizándose por capricho y luego teniendo problemas extraños.
• Externos funcionan entre servidores, repositorios y carpetas en el mismo repositorio. Entonces, puede mover los binarios a otro servidor/repo y simplemente vincularlos con externos.
• Reestructurar las carpetas para que pueda rastrear el proyecto y seguir pudiendo trabajar productivamente. Básicamente, todo el mundo revisa la carpeta superior + hijos solo, luego de forma selectiva "actualizar para revisar" las carpetas que necesitan para pagar por completo.
• Crea scripts que exportan, compilan y luego confirman (o solicitan confirmación). Tengo tales scripts para mi uso. Antes de comprometerme, ejecuto el script y exporta mi wc y luego compila. NOTA: ¡Esto copiará el wc completo!Por lo tanto, esto es útil con los checkes dispersos donde el tamaño de los datos es pequeño (er).
• Considere mover los binarios del repositorio (no lo recomiendo, pero podría ser la solución más segura para volver a subir la productividad).
• Recuerde, exportar no crea un wc, lo que significa que ahorra un 50% de espacio en disco en comparación con las cajas. Por lo tanto, si se reestructura de manera tal que los binarios y los elementos que se actualizan con poca frecuencia se puedan exportar en lugar de pagar, se alentaría a más personas a "aprovechar al máximo" y no tratar de echarle un vistazo.