Diario de Programación

¡¡ Por fin tenemos nuestro primer proyecto migrado a subversion !!.

La historia ha sido una verdadera odisea. Normalmente usamos CVS, pero en el momento de empezar a trabajar con ramas un poco en serio, el tema se hacía demasiado pesado. CVS crea las ramas recorriendo todos los ficheros del repositorio y marcando la rama para cada uno de ellos. Crear una rama en CVS tardaba cerca de media hora en cada proyecto implicado. Subversion, al tener todo el repositorio con un número de versión único, no necesita recorrer todos los ficheros uno a uno para hacer la rama, le basta con marcar en algún sitio que en ese número de versión comienza una rama. Tarda como la mitad de medio segundo (es un decir) en hacer la rama de un repositorio, independientemente de la cantidad de ficheros que haya almacenados.

Por otro lado, nuestro servidor de CVS se estaba quedando "viejito". Una estación solaris del año del "catapúm" con 128 megas de ram (al que hace poco se le estropeo un módulo de 64 y creo que de esos ya no hay ni el rastro), con el disco duro (de pocos gigas) permanentemente al 99%. Total, que se imponía también un cambio de máquina.

Así que aprovechando lo uno con lo otro, decidí que nos pasabamos a Subversion en un servidor nuevo. Dicho….. y a esperar.

Primero convencer a la gente de las excelencias de Subversion sobre CVS. Como siempre, a unos pocos les parece estupendo, a muchos les importa tres pepinos y a algunos lo de "¿Para qué vamos a cambiar si ahora funciona?". A base de dar la paliza, conseguí convencer (o al menos dejaron de protestar) a todos.

Después lo de conseguir el servidor nuevo. Ni el departamento ni los proyectos para los que trabajamos estaban dispuestos a comprar un servidor (pensé seriamente en ir a tomar los cafés encima del servidor actual, para que ocurriera "una desgracia"). Así que a negociar con el departamento de informática de la empresa, a ver cuánto nos cobran por darnos un subversion en uno de sus servidores. Tras mucho tira y afloja (y sobre todo gracias a la persona que nos hizo de intermediaria en la software lab con la que trabajamos), nos dieron el subversion gratis. Entre pedir el servidor a los proyectos, intentar convencerles y hablar con el departamento de informática pasaron casi dos meses.

Y hoy, por fin, la primera migración. Me bajé el cvs2svn e intenté migrar uno de nuestros proyectos. Desgraciadamente, intenté hacerlo sobre windows y no hubo manera. Tenía el cygwin y teóricamente todo lo necesario, pero me fallaba en un punto en el que se hace una llamada al comando "sort". El de windows no vale, porque funciona distinto del de unix. El de cygwin aparentemente me daba problemas porque se liaba con las \ de los directorios (al ser unix, espera / de directorio). Me bajé los UnxUtils, pero al ejecutar el comando sort daba un error muy raro (insuficiente espacio en disco, o algo así, habiendo más de 20 Gigas libres). Así que reinicié el ordenador para arrancar en linux y ahí fue todo rodado a la primera.

Total, ya tenemos nuestro primer proyecto en subversion. El primero de una larga lista de ellos que debemos ir migrando poco a poco.

Ultimamente me ha dado por probar algunas herramientas nuevas e incluso volver a probar algunas que ya había probado. En concreto, me he vuelto a instalar un servidor de subversion, he vuelto a intentar instalar trac, también otra cosa que he encontrado por equivocación y que se llama traks (una aplicación web para usar GDT, con lo cual me resultó interesante), etc, etc.

Como soy vago y encima estoy mal acostumbrado a Windows, para todas ellas me he buscado instaladores de windows, de esos que se instala todo solo con un par de clicks. En concreto, he usado los instaladores de bitnami, u otros del estilo, cuya principal ventaja es que con un par de clicks instalan TODO lo necesario para tener la aplicación funcionando.

Y la ventaja de estos instaladores es precisamente su problema.

Casi todo lo que he instalado son aplicaciones web, así que creo que tengo todos los puertos desde el 8080 al 9999 ocupados con servidores apache, cada uno para su aplicación. Debo tener como tres o cuatro versiones de python instaladas en distintos directorios (que además ya tenía instaladas previamente), varios servidores MySql y sabe Dios cuántas cosas más por tripitido.

Menos mal que después de probada un poco la aplicación, se desinstala igual de fácil que se ha instalado.

Por cierto, los tra* no me van bien. trac me sigue pareciendo demasiado complejo de configurar sin el instalador, aparte de que me da errores al ejecutar los python. Y el bitnami stack de track, después de la instalación, me ha fallado en el arranque, por lo que no he podido siquiera verlo en marcha.

Hace poco me tocó hacer una rama CVS de los proyectos para estabilizar una versión para unas pruebas con el cliente. Ya se sabe, rama del repositorio del proyecto y rama de todos los repositorios con librerías que utilice el proyecto.

Pues bien, ha sido horrible. Son cuatro o cinco repositorios y cada uno de los proyectos/librerías a "enramar" tienen fácilmente tres mil ficheros java. Eché toda la tarde en hacer las dichosas ramas. Primero un update, luego el cvs tag para poner una etiqueta justo en el punto donde comienza la rama y luego el cvs tag -b para crear la rama. Al hacerlo CVS fichero a fichero, media hora larga con algunos de los repositorios mientras cvs hace el trabajo.

Se me ocurrió, harto de ello, montar un servidor de subversion, migrar alguno de los repositorios CVS a subversion (usando cvs2svn) y mirar a ver cuánto tarda subversion en hacer la rama (svn cp). Es casi inmediato, ya que realmente no realiza la copia real de todos los ficheros (lo hará cuando se vayan modificando si se van modificando) y tampoco tiene que andar recorriendo todos los ficheros para ver su versión actual (CVS tienen un número de versión para cada fichero, mientras que subversion tiene un único número para todo el repositorio).

Todo el mundo habla que los sistemas de control de versiones distribuidos, estilo Bazaar o Git son maravillosos. También se habla mejor de Subversion que de CVS, aunque no todos lo hacen. A mí realmente todo eso me parece bien, pero mientras no veo una necesidad real o una mejora importante, no veo tampoco necesidad de cambiar. Ahora sí he encontrado un motivo, así que es cuestión de empezar a mirar en serio la posibilidad de migrarlo todo a Subversion.

De momento descarto Bazaar o Git por tener menos soporte para los IDEs habituales (eclipse en concreto). Tampoco tengo muy claro lo veloz que puede ser hacer un branch de un repositorio grande si eso implica la copia completa de todo el repositorio, con su historia (ya digo, repositorios de tres mil clases java con cuatro o cinco años de historia y alrededor de veinte desarrolladores de media desarrollando día a día).