it-swarm-es.tech

¿Cómo puedo acelerar las actualizaciones de SVN?

Tenemos un repositorio SVN bastante grande. Las actualizaciones de SVN tardan más y más cuanto más agregamos código. Agregamos svn:externals a carpetas que se repitieron en algunos proyectos como FCKeditor en varios sitios web. Esto ayudó, pero no tanto.

¿Cuál es la mejor manera de reducir el tiempo de actualización y aumentar la velocidad de SVN?

26
EtienneT

Si se trata de un repositorio SVN más antiguo (o incluso bastante nuevo, pero no se configuró de manera óptima), tal vez utilice el estilo BDB más antiguo de la base de datos del repositorio. http://svn.Apache.org/repos/asf/Subversion/trunk/notes/fsfs tiene notas sobre el nuevo. Cambiar de uno a otro no es demasiado difícil: volcar todo el historial, reiniciarlo con el nuevo formato svn del sistema de archivos y volver a importarlo. También puede ser útil al mismo tiempo filtrar el volcado de repositorio para eliminar registros completos de información inútil (por ejemplo, eliminé 20 MB + archivos tarball que alguien había registrado).

En lo que respecta a la velocidad general, un disco duro de calidad (veloz) y memoria adicional para el almacenamiento en caché basado en el sistema operativo sería difícil de criticar en términos de aumentar la velocidad de cómo funcionará SVN.

En el lado del cliente, si tiene que configurar tortugas a través de PuttyAgent para el acceso SSH a una máquina de repositorio externo, también puede habilitar la compresión SSH, que también puede ayudar.

Editar: SVN v1.5 también tiene la herramienta fsfs-reshard.py que puede ayudar a dividir un repositorio svn basado en FSFS en una serie de directorios, que se pueden vincular a diferentes ejes de unidad. Si tiene miles de revisiones, eso también puede ayudar, si no es por otra razón que encontrar un archivo entre miles lleva tiempo (y usted puede saber si eso es un problema mirando los tiempos de IOwait)

14
Alister Bulman

Deshabilite la comprobación de virus en carpetas que contienen código de copia de trabajo. Esto causó que mis actualizaciones fueran dos veces más rápidas.

10
Lee Englestone

No es realmente una respuesta, pero puede ser interesante saber que una de las razones por las que svn es tan pesado en E/S es el hecho de que almacena una copia adicional de cada archivo en el directorio .svn/text-base. Esto hace que las operaciones de diferenciales locales sean rápidas, pero consume mucho espacio en disco duro y E/S.

http://Subversion.tigris.org/issues/show_bug.cgi?id=525 tiene los detalles.

5
Erik Forsberg

Parece que tienes varios proyectos en un repositorio. Dividirlos donde sea apropiado te dará un gran impulso.

Supuestamente, Git es mucho más rápido que Subversion debido a la forma en que almacena/procesa los cambios, pero no tengo experiencia de primera mano con él.

4
ceejayoz

Hay algunos ajustes de rendimiento comunes. SVN es muy pesado en E/S, por lo que los discos duros más rápidos son una opción (en ambos extremos). Agregue más memoria a su servidor. Asegúrese de que sus clientes tengan un disco duro desfragmentado (para Windows).

El método de acceso que use también es importante. Los repositorios almacenados en sistemas de archivos remotos (usando file: /// access) serán mucho más lentos que svnserve o Apache con mod_svn. Considere usar uno de estos últimos si tiene el repositorio en un recurso compartido de archivos simple.

3
Yann Ramin

Asegúrese de que su conexión al servidor sea lo más rápida posible (ethernet gigabit). Asegúrese de que el servidor tenga discos rápidos en una matriz. Y, por supuesto, solo revisa lo que necesitas.

3
WildJoe

TotoiseSVN por defecto mira los cambios de archivo en segundo plano y he visto que esto ralentiza mi máquina. Cambié la configuración para excluir todo y luego solo incluir los directorios donde tengo que pagar. También puede desactivar las verificaciones de antecedentes. Ambas configuraciones están en el nodo de configuración de Superposiciones de iconos.

2

A veces, la operación svn lenta, especialmente con muchos elementos externos, está relacionada con DNS. Parece que svn realiza una búsqueda de DNS por cada svn: externo, incluso para los relativos. Agregar su nombre de host del servidor svn a/etc/hosts o arreglar resolv.conf puede ser útil.

2
Vasily Redkin

He encontrado en mi propia experiencia (es decir: no a través de ninguna pruebas reales ) que, especialmente si el servidor de repositorio SVN es remoto, parece que el uso externo ralentizar las cosas. Si tiene código duplicado (como su editor FCK) en varios lugares, tendería a seguir usando externos, ya que mantener esos archivos sincronizados y manejables es más importante que las velocidades de actualización; sin embargo, podría usar enlaces simbólicos para traer en código duplicado en su lugar. (Si usa Windows XP, puede usar puntos de unión ).

1
nickf

El uso de derechos de acceso de lectura (es decir, restringir el acceso de lectura a ciertas personas/grupos) ralentizará mucho el repositorio. Especialmente cuando la autenticación se realiza de alguna manera especial, p. contra un dominio de windows. Lo mismo ocurre con los derechos de acceso de escritura, por supuesto, pero la escritura es menos frecuente que la lectura. Y restringir el acceso de escritura puede ser más importante que restringir el acceso de lectura

1
anonymous

Dividimos nuestra base de código en varios módulos hermanos y escribimos los scripts Ant para que un desarrollador pueda trabajar en un módulo a la vez sin preocuparse demasiado por lo que sucede en los otros módulos.

  • un script de compilación de nivel superior activa todos los scripts de compilación de módulos
  • las bibliotecas externas se almacenan en no en Subversion, sino que se extraen de una unidad de red con Apache Ivy. (piense en ello como un repositorio interno de Maven).
  • las dependencias entre módulos también se gestionan con Ivy.

Por lo general, los desarrolladores necesitarán actualizar su árbol completo un par de veces a la semana, pero se puede hacer fácilmente antes de ir a almorzar/tomar un café.

1
Vladimir

Si tiene muchas carpetas en la raíz del repositorio y su copia local refleja el repositorio, intente cortar la copia local monolítica en muchas carpetas descargables separadas y actualizar estas carpetas por separado también, será realmente más rápido que una carpeta grande.

0
noetic