Las mejores prácticas para un solo gran proyecto SVN

Question

He heredado un solo proyecto en SVN: 30 Gb en más de 300 000 archivos. Hay un montón de archivos binarios en su mayoría no en una carpeta de imágenes. Operaciones como la actualización de todo el proyecto pueden ser dramáticamente lento.

El equipo ha desarrollado un proceso para única actualización / interruptor de marcha en las carpetas específicas que están trabajando y que terminan en la comprobación de código roto porque "funciona en mi equipo". copia de trabajo de una persona determinada puede incluir el código fuera de la fecha de código, conmutada, y el código-cometido nunca olvidado. Además, un mínimo de ramificación tiene lugar.

Mi solución personal es una pequeña fiesta de la caja / Creación de un script a las 5 am cada mañana, sin embargo, no todo el mundo tiene el valor de línea de comandos para copiar incluso mi solución y prefieren la comodidad de tortoisesvn y el proceso roto.

Alguien ha tratado de sintonizar un gran repositorio de este tipo y puede dar consejos? ¿Hay mejores prácticas que pueden poner en práctica para trabajar con grandes repositorios que pueda facilitar a todos en?

P.S. externos no parecen ser una buena idea y SVN optimizaciones para mantener grandes repositorios de respuesta no se aplica aquí porque estoy tratando con un solo proyecto

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

Answer 1

En primer lugar, actualizar a 1.6 SVN en cliente y servidor. Toma nota de la última liberación mencionan un aumento de velocidad de archivos de gran tamaño (r36389).

En segundo lugar, esto no puede ser demasiado apropiada para usted si usted tiene que tener todo el proyecto en su copia de trabajo, pero el uso de directorios escasos . Hacemos esto para nuestra gran repo, la primera cosa que un cliente hace es obtener el directorio de nivel superior solamente, a continuación, para obtener más datos, utilizar el navegador de repositorios para ir al directorio deseado y "actualización de esta revisión" en él. Funciona de maravilla en TortoiseSVN. 1.6 también tiene la opción de 'reducir la profundidad' para eliminar los directorios que ya no necesita trabajar.

Si esto no es para usted, usted puede todavía hacer una actualización de las partes de la copia de trabajo. Actualización tiende a ser lento cuanto más archivos que tiene (en Windows, es decir, NTFS parece ser particularmente pobre, con la estrategia de bloqueo utilizado para la actualización. Bert Huijben cuenta de esto y sugirió una solución -. TBA con el lanzamiento 1.7, pero se puede reconstruir su 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 conductor, pero estoy seguro de que sería prudente de eso!

Última opción - apagar el escáner de virus para Svn firectories, y también para el repositorio en el servidor. Si se está utilizando Apache en el servidor, asegúrese de que tiene mantener conexiones activas durante un breve periodo de tiempo (para prevenir la re-autenticación que se produzcan). También desactivar la indexación en los directorios de copia de trabajo y copia de sombra también. (El último no ayuda mucho, pero es posible que vea una mejor mejora que lo hice, girando fuera de AV en el servidor impulsado mi 10x respuesta SVN sin embargo).

Answer 2

Tenemos dos depósitos, uno para nuestros códigos (cambia con frecuencia) y otro para los datos binarios (muy grande), los cambios con poca frecuencia. Es un dolor a veces, pero vale la pena la mayor velocidad cuando se trabaja con código.

También tenemos un script Ruby que llamamos "actualización diaria", registrado en nuestro repositorio, que arranquemos en todos nuestros ordenadores a través de un desarrollo de tareas programadas de Windows, temprano por las mañanas. En él se actualiza ambas cajas a la última versión, entonces construye todo a nivel local, así que estamos listos para ir tan pronto como llegamos en la mañana.

Hay algunos contratiempos que no hemos subsanadas sin embargo - por ejemplo, cuando nuestras pruebas automatizadas se ejecuten, no hay actualmente un retraso entre el momento en que se compruebe el código y cuando se echa un vistazo a los datos, así que cuando nos comprometemos cambios a ambos repositorios, el servidor de CI a veces se pone código antiguo y los nuevos datos, lo que provoca fallos en la prueba.

Cuando cometemos cambios en el repositorio de datos, por lo general sólo decimos a todo el mundo que necesitan para actualizar (todos sentados en la misma habitación). De lo contrario, que no suele actualizar los datos de forma manual; dejamos que el script de actualización diaria mantenerlo fresco.

Answer 3

Para hacer frente al tamaño difícil de manejar, me gustaría considerar disociación de datos binarios en otra rama (o incluso eliminar por completo que pueda ser almacenada en otro lugar), separado del código. Esto debería al menos acelerar las cosas, sobre todo si los datos no cambian con frecuencia.

Yo entiendo la necesidad de que la gente tenga una ubicación central para sus herramientas, datos y bibliotecas, pero simplemente no funciona bien tener un vertedero.

Answer 4

Voy a ser breve:

• Actualizar a la última versión (1.6.x). 1.5.x tenía optimizaciones de velocidad también.
• Asegúrese de que todos estén utilizando la misma versión de TortoiseSVN que se construye en contra de la versión exacta del servidor. Tuvimos muchos problemas con la actualización de los chicos en el capricho y luego conseguir problemas extraños.
• Elementos externos de trabajo entre servidores, repositorios y carpetas en el mismo repositorio. Por lo que puede mover los binarios a otro repo / servidor por completo y sólo vincula a ellos con lo externo.
• Reestructurar las carpetas para que pueda escasa partida de los proyectos y aún así ser capaz de trabajar de forma productiva. Básicamente todos pasan a cabo encabeza la carpeta + niños sólo entonces selectivamente "Actualizar a la revisión" las carpetas necesarias para la comprobación totalmente.
• Crear guiones que exportan, construir a continuación, confirmar (o pronta a cometer). Tengo este tipo de scripts para mi uso. Antes de comprometerse, corro el guión y exporta mi wc y entonces construye. NOTA: Este copiará el aseo completo! Así que esto es útil con obtenciones parciales donde el tamaño de los datos es pequeño (er).
• Considere mover los binarios fuera de la cesión temporal (no recomiendo esto, pero podría ser la solución más sensata para conseguir la productividad de nuevo).
• Recuerde, la exportación no crea un aseo, que permite ahorrar espacio en disco de 50% en comparación con las cajas. Así que si reestructura de tal manera que los binarios y artículos actualizados con poca frecuencia pueden ser exportados en lugar de la salida, que alentaría a más personas a "conseguir la cosa completa" y no tratar de rozar algo de él.

Answer 5

Yo era un gestor de SMC en una situación similar. Tuvimos un proyecto con más de 200 mil archivos de código (en su mayoría) que estaba teniendo algunos de los mismos problemas. Nuestra solución fue dividir el depósito en dos versiones. Una versión es una versión de desarrollo y la otra es una versión de producción. Sembramos la versión de desarrollo con la última y mejor conocida copia de trabajo de todo el código. Los desarrolladores comenzaron con eso y hacen cambios, comprobado de entrada / salida, etc. Una vez que se sentían cosas se mantuvieron estables, un administrador (en nuestro caso un gerente de construcción) se fusionaron el código y lo hicieron compilación de prueba para verificar todo funcionaba correctamente. Si todo pasó fue bueno. Si no lo hiciera el administrador acumulación cazaría el desarrollador y castigar severamente. Tuvimos algunos de los mismos problemas en el comienzo donde "Funcionó en mi equipo", etc., pero en poco tiempo los fueron elaborados gracias a los golpes y latigazos .....

En particular, los puntos del código de desarrollo (CODIGO DE TRABAJO TODO !!!!) se fusionó de nuevo en el ciclo de producción y comunicado al cliente.

Answer 6

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