miércoles, noviembre 14, 2012

Arreglando un problema con los tags de svn

Esta mañana me dí cuenta que la aplicación de replica automática de configuraciones tenía un problema con el manejo del repositorio y la creación de los tags (las etiquetas se crean cuando hay un cambio en la configuración de algún dispositivo).

Inicialmente, la aplicación hacia un checkout de todo el repositorio (svn checkout http://repositorio/, que incluye trunk/, tags/ y branches/) pero como en subversion etiquetar es hacer una copia de todo el árbol completo de trunk (svn copy trunk/ tags/nueva-etiqueta; svn commit -m "tag nueva-etiqueta") producía el efecto indeseable de que cada checkout posterior fuera más y más grande. En los inicios esto no supone un problema serio, pero cuando hayan pasado 100 días y si el repositorio ocupara 10 MB, el checkout ocuparía 1 GB (se ejecuta una vez al día y siempre en los dispositivos, aparece alguno que se ha cambiado su configuración, aunque sea en uno sólo, teniendo que hacer el tag), la cosa cambia muchísimo.

Así que me puse a arreglar el problema. La solución es traerme sólo trunk/ (svn checkout http://repositorio/trunk/) y el etiquetado lo hago sobre el propio repositorio (y no sobre la copia local como hacia antes) con el comando svn copy http://repositorio/trunk/ http://repositorio/tags/nueva-etiqueta -m "tag nueva-etiqueta". Se parecen, pero no son iguales.

En subversion los tags son perezosos, no consumen espacio en el repositorio, pero cuando se hacen los checkout de un tag, este sí que se despliega. Si haces el checkout de todos los tags, tendrás todos los tags desplegados.

La verdad que es díficil de ver el problema, sólo me dí cuenta cuando empece a ver en los logs que la operación de checkout inicial cada vez tardaba más en hacerse y cuando lance un du sobre la copia de trabajo, quedó claro el problema.
~/automatic_safe_config$ du -h --max-depth=2 -x
10M ./tags/t20111101
10M ./tags/t20111102
10M ./tags/t20111103
10M ./tags/t20111104
10M ./tags/t20111105
10M ./tags/t20111106
10M ./trunk/
1K. ./branches/
70M ./
Es curioso que antes de dar con la solución, maneje la alternativa de quitar los tags o de pasarme a git. La primera no me gustaba, puesto que quería disponer de la posibilidad de echarle un vistazo rápido a los cambios de configuraciones sin tener que tirar un cliente svn, navegando por los etiquetas. La segunda implicaba muchos mas cambios (montar un servidor git y cambiar todos los comandos svn por sus equivalentes git), y no sabía si iba a tener otro tipo de repercusión.

No hay comentarios:

Publicar un comentario

Cómo utilizar el servicio Secrets Manager para guardar las claves privadas de SSH

Para guardar la clave privada en el servicio Secrets Manager como un secreto en modo texto sin formato, sigue estos pasos Supongamos que la ...