Versiones

Como muchos de los lectores del presente se han de imaginar, estudié la carrera de Ingenieria en Sistemas (de Información, para ser exactos), sin embargo hoy no voy a hablar de las implicaciones morales y éticas de haberlo hecho, ni de la forma en como encajan los ISI's en el ambiente laboral, ni tampoco del lugar a donde ha ido esta subespecie de profesionista en Tecnologías de Información, ahora que el H. ITESM tiene una nueva carrera para esta área.

Tampoco voy a contar como llegué a donde estoy, y no porque no sepa, sino porque durante los últimos 26 años de mi vida he tomado suficientes decisiones torcidas como para cuestionar mi sanidad (y me rehuso a dar más argumentos al respecto (ya hay suficientes lectores de este blog que los tienen)).

El caso es que por culpa del primer párrafo (y gracias al segundo es que puedo ir directo al grano), mi trabajo actual consiste en desarrollar una aplicación web utilizando Visual Studio .Net 2005. El caso es que la semana pasada se entregó la versión 4 del sistema y empecé a trabajar en la versión 5.

Todo era felicidad en el ambiente de desarrollo, las hojas de estilo por fin pudieron ser aprovechadas y los controles de usuario por fin pudieron ser utilizados de manera eficiente. Todo iba tan bien, hasta que ocurrió lo que siempre ocurre en la ingeniería en sistemas: el cliente pidió algo que no estaba en los requerimientos.

El caso es que era necesario hacer algunas modificaciones a la versión 4 del sistema. Pero el código base debería ser la versión 4 (es decir, tenía que añadir funcionalidad, sin incluir el código en el que había estado trabajando durante los últimos días). Este código tendría que formar parte de una nueva entrega para la versión 4.1 , y una vez aprobado, pasaría a formar parte del código en que está basada la versión 5. Nada del otro mundo, sólo una oportunidad para que se presente mucho retrabajo y la posibilidad de perder código en el proceso...

Como parte del ambiente de desarrollo, estoy utilizando Visual Source Safe 6.0d y a pesar de tener casi 6 años de utilizarlo (aún no entiendo por qué en ninguna materia de la carrera se nos orientó acerca de la existencia de los sistemas de control de versiones (algo que intenté corregir durante el tiempo que tuve la oportunidad de impartir clases a estudiantes de sistemas)) nunca había utilizado la funcionalidad de branch y merge.

Estaba casi seguro que me iba a topar con algún inconveniente. Pues, a pesar de que durante unos 2 años trabajé muy a gusto con Source Safe, una vez que conocí Subversion me di cuenta que estaba en el lado oscuro.

Y esta vez Source Safe no me decepcionó en su lista de problemas. La funcionalidad de branch y merge del Source Safe es tan pobre, y tan errática, que terminé haciendo esa funcionalidad a mano, sin la ayuda de la herramienta. Tener que hacer el merge archivo por archivo tal vez está bien para un proyecto de... mmm... ¿un archivo?. Pero para un proyecto de varias docenas de archivos, esto es poco peor que 'extremadamente ineficiente'. Y no sólo es el problema de hacer el merge de archivo por archivo. Si no que no hay una forma amigable de arreglar los conflictos entre versiones.

Realmente no entiendo óomo es que Microsoft puede vender una herramienta que no hace nada bien (en realidad sí entiendo, supongo que lo que no entiendo es cómo los usuarios la siguen utilizando (en realidad también entiendo (por eso estamos como estamos))). Supongo que lo único que más o menos funciona de Visual Source Safe es la integración con las demás herramientas de desarrollo de Microsoft. Pero... ¿Quién quiere tener integración con una herramienta mal lograda?. Muchos de los lectores de este blog conocieron mis días en que defendía a Source Safe a capa y espada. Pero esos días terminaron hace al menos 2 años. Desde entonces, fui migrando mis repositorios de código a Subversion, el cual sí me permite hacer branch y merge de una manera apropiada. Y ya no voy a mencionar (de hecho sí estoy mencionando) la posibilidad de acceder el repositorio por web, la rapidez de búsqueda de versiones, los repositorios casi no se corrompen, los commits atómicos (gran ventaja), el costo de la licencia, etc, etc.

Al parecer la versión 4.1 se ha congelado y a partir de ahora sí podré trabajar con ese código como la base para la versión 5. O al menos eso es lo que el final feliz del cuento de hadas predice, la realidad es que de un momento a otro, puede aparecer un cambio en los requerimientos que me haga necesitar hacer un branch (y más tarde su respectivo merge)... y en ese momento, Source Safe me dejará sólo en la batalla (me recuerda algunas escenas de los juegos de rol de Robotech que solíamos jugar cuando era estudiante, donde a mitad de un dogfight 3 vs 2, uno de los dos últimos termina volando detrás de una montaña, para regresar justo cuando han derribado al VF solitario.)

Desafortunadamente en muchas partes tenemos que utilizar Source Safe como herramienta de control de versiones, no tanto por gusto, sino por obligación (políticas organizacionales, requerimientos del cliente, letras pequeñas en algún contrato de otro producto de Microsoft, etc.). Ya me ha tocado 2 veces perder código crítico por culpa de la herramienta de Microsoft, y desde entonces, me hice el propósito que no me volvería a suceder. No voy a confiar mi espalda nuevamente para que Source Safe la cubra. Ahora subversion es mi wingman de confianza.