SourceSafe: Control de versiones

1. Introducción

En el desarrollo de aplicaciones es importante (casi diría imprescindible) llevar un control de los cambios en el código fuente, especialmente cuando en dicho desarrollo intervienen varias personas. Para esta función tenemos varios programas (TeamSource de Borland, Git para Linux o SourceSafe de Microsoft).

Además, con bastante frecuencia necesitaremos tener los fuentes según estaban en un momento concreto del tiempo, con el objetivo que modificar algún error en la misma. Por ejemplo, el código fuente que corresponde a la versión de la aplicación que está desplegada en producción, ya que, como es evidente, no nos sirve la última versión del código fuente, puesto que ésta puede tener cambios que todavía no están preparados para pasar a producción.

En este documento vamos a definir los principales pasos para llevar un control del código fuente utilizando Microsoft SourceSafe 6.0, así como la gestión de las distintas versiones de un proyecto. No obstante, este documento no pretende suplantar la ayuda en línea en MSDN (muy completa en este caso):


2. Proceso de gestión de versiones

A lo largo del presente documento vamos a suponer un caso real, que va a ir evolucionando y en el que vamos a ir aplicando las secciones que mostramos.

Además, para los ejemplos concretos utilizaremos un proyecto en Microsoft Visual Studio 2005, aunque todas las acciones a llevar a cabo las realizaremos directamente en SourceSafe, con lo que no es en absoluto necesaria dicha herramienta.


2.1. Etiquetas (Flags)

Una vez el desarrollo de la aplicación alcanza un objetivo, llega el momento de poner una marca al código fuente indicando esta situación, especialmente con la idea de tener la posibilidad de volver a este punto del desarrollo en el futuro. Para ello se utilizan las “Etiquetas” o “Flags”, tal y como se puede observar en la imagen:


Aquí nos saldrá una ventana en la que nos pide un nombre para esta Etiqueta (hasta 31 caracteres), así como una descripción de la misma. Es mejor no ser demasiado críptico con el nombre ni demasiado rácano con la descripción, ya que cuando lo tengamos que utilizar en el futuro es mejor no tener que especular sobre qué queríamos decir semanas (o meses) antes.

De esta forma SourceSafe pone la etiqueta en la versión actual a todos los archivos que forman parte de la solución.

En nuestro ejemplo, vamos a suponer que los fuentes han alcanzado un grado de madurez suficiente como para liberar la versión 1.0 de nuestra aplicación, con lo que en el nombre de la etiqueta vamos a poner “v1.0”, y en la descripción algo como “Primera versión estable en producción”. Nótese que la etiqueta se la ponemos a todo el proyecto.


2.2. Mostrar Historial (Show History)

Desde SourceSafe siempre tenemos la opción de ver el historial de un elemento (proyecto, carpeta o simple archivo). Al hacerlo, ya sea desde el botón derecho o desde el menú Archivo, tendremos una imagen que se parecerá a esta (imagen tomada marcando la opción de “Recursivo” para que muestre el histórico de todas las carpetas que contiene el proyecto):


Desde este momento empezamos a modificar el proyecto con nuevas funcionalidades y correcciones con el objetivo de ir preparando una nueva versión del mismo. Así, el histórico pasa a mostrar este estado de los archivos del proyecto:


Es en este momento cuando detectamos (realmente nos lo detectan) un error en el programa que tenemos en producción, y que tiene que ser corregida inmediatamente. La versión que hay en producción es la v1.0, pero nuestros archivos con el código fuente ya han sufrido algunas modificaciones, lo que hace que no las podamos utilizar para corregir este error porque incluiríamos cambios que todavía no están aprobados.


2.3. Compartir (Share)

Con la acción de Compartir creamos una copia de los archivos del proyecto a partir de un momento dado. En nuestro caso, lo que necesitamos es modificar el código fuente según estaba en el momento de la versión 1.0, con lo que buscamos en el histórico esta Etiqueta (podemos seleccionar “Mostrar sólo etiquetas” en la ventana de búsqueda para simplificar la selección):


En la siguiente pantalla nos da la opción de indicar desde dónde compartimos (“Compartir desde …” en español o “Share from …” en inglés), pero lo de opción no es muy correcto. En la práctica hay que pegarle al raíz (root) del proyecto. Es importante que no esté marcada la casilla de “Bifurcar después de compartir” (“Branch alter share”).



A continuación nos pide un nombre, y en honor a la originalidad de ponemos “PruebaVersiones v1.1”. Nuevamente, es importante que esté marcada la casilla de “Recursivo” para no dejarnos los subproyectos que pueda tener.

Este proyecto compartido no tiene definido ningún directorio de trabajo, así que podemos pasar a indicárselo. Es recomendable nombrar el directorio de una forma suficientemente clara para evitar confusiones. En este caso vamos a crear un nuevo directorio de trabajo (Working Folder) llamado igual al nombre compartido: “PruebaVersiones v1.1”, aunque podríamos ponerle cualquier otro. Una vez hecho esto nos traemos la última versión de la forma habitual (marcando “Recursivo” y “Construir árbol de directorios”).

De esta forma ya tenemos los archivos tal y como estaban en el momento en el que le pusimos la etiqueta de v1.0, sin los cambios posteriores. Sin embargo esto no es una copia, sino que SourceSafe sigue controlando internamente las diferentes acciones en los archivos. Para empezar, el hecho de “Compartir” hace que todos los archivos creados como v1.1 estén “Fijados”, es decir, están marcados de tal forma que no nos permite ninguna modificación en los mismos.


2.4. Bifurcar (Branch)

El siguiente paso es quitar la fijación (desfijar suena demasiado mal) de los archivos que necesitan ser modificados para corregir los errores encontrados en producción. Para ello utilizamos la opción de bifurcarlos en lugar de simplemente quitarles esa fijación (me estoy dando cuenta que esto tampoco suena muy bien).

La diferencia entre “Desfijar” (“Unpin”) y “Bifurcar” (“Branch”) es que el segundo permite volver a combinar los cambios con la versión inicial de una forma automática, mientras que el primero no. Por lo tanto, aplicamos la bifurcación al archivo que tenemos que modificar, esta vez desde el menú “Versiones -> Bifurcar” teniendo seleccionado el archivo deseado (yo tampoco entiendo porqué no está la opción en el menú contextual o “de botón derecho”).


Una vez hecho ya podemos hacer las modificaciones necesarias en dicho archivo. Generar nuevamente el proyecto, probarlo, instalarlo en producción y cualquier cosa que queramos o necesitemos según nuestra metodología de trabajo (si tenemos).

Después de realizadas las modificaciones para la versión 1.0, es posible que queramos incluirlas también en la versión actual del proyecto. Recordemos: esa que está en plena fase de desarrollo con el objetivo de lanzar la versión 2.0. Esto lo podemos hacer de forma manual en el código fuente actual, pero también puede que queramos, sin encomendarnos a nadie, que sea el propio SourceSafe de forma automática.


2.5. Combinar versiones bifurcadas (Merge Branches)

Esta es la forma en la que SourceSafe incluye los cambios de una versión de un archivo en otra. Para ello se selecciona el archivo en el que queremos incluir las modificaciones hechas, a través del menú “Versiones -> Combinar versiones” (ésta opción tampoco está en el menú contextual; las preguntas a Microsoft):


Insisto: “en el archivo en el que queremos incluir las modificaciones”. Es decir, si nuestra intención es incluir en el archivo de desarrollo actual (próximo a la versión 2.0) los cambios hechos en la versión antigua (etiquetada como v1.1) es el archivo actual el que debemos tener seleccionado al pulsar esta opción.

A continuación nos aparece una ventana en la que tenemos que elegir con qué archivo lo queremos combinar. Lo normal es que elijamos el mismo archivo de la versión v1.1. Por suerte, SourceSafe está atento y sólo nos habilita el botón de Combinar (Merge) cuando hemos seleccionado un archivo válido.


El ojo hábil habrá notado que he cambiado el fichero de la prueba (antes Class1.cs, ahora Form1.cs). El motivo es que el previo ha sufrido demasiadas pruebas y la pantalla de ejemplo no iba a ser nada clara.

Cabe la posibilidad de que tengamos conflictos en este proceso, principalmente cuando la misma línea ha sido modificada en ambas versiones. En estos casos nos saldrá una ventana en la que tendremos que indicar qué líneas tienen que ser incluidas en la versión. Esta elección se realiza de una forma visual y totalmente intuitiva, “pinchando” el cambio que queremos incluir (se pueden incluir ambos). Francamente, me ha sorprendido (para bien):


Con esto ya tenemos los cambios tanto en el parche para salir del paso en producción (versión 1.1) como en la versión del código fuente en desarrollo. Sólo nos queda volver a “Fijar” los archivos modificados.


2.6. Fijar (Pin)

Una vez que hemos terminado de hacer los cambios, lo ideal es volver a “Fijar” los archivos de la versión v1.1. ¿Para qué? Para evitar que en un descuido volvamos a modificar esta versión y olvidemos propagar el cambio a la última versión del código fuente.

Desde mi punto de vista (que es personal e intransferible) es preferible que para volver a hacer una modificación sobre esta versión “del parche”, tengamos que repetir los pasos de “Bifurcación” y “Combinación”.

Para fijar manualmente una versión de un archivo (la vez anterior se fijó de forma automática al compartirla) abrimos su histórico y pulsamos en el botón Fijar (Pin):



3. Conclusión

Los sistemas de control de versiones (SCV) como Microsoft SourceSafe son muy útiles, abarcando una amplia gama de funciones desde el simple sistema de copia de seguridad del código fuente, hasta tareas mucho más complejas como gestión de Ramas (Bifurcaciones o Branches) como la que se ha apuntado ligeramente en este documento.

La utilización de estos SCV se vuelve imprescindible cuando la complejidad de los programas crece, tanto por su tamaño como por las personas involucradas en su desarrollo.

Independientemente de (o además de) estos motivos, es una buena idea mantener los saludables hábitos de su (correcta) utilización para evitar sustos y disgustos cuando la vida real se cruza con la bonita teoría del diseño y desarrollo de aplicaciones.


4. Enlaces

Como dijimos al principio, todo lo nombrado en este documento está mucho mejor explicado en la página de la ayuda de MSDN de Microsoft SourceSafe:

http://msdn2.microsoft.com/es-es/library/ms181038(VS.80).aspx


Sin embargo, no es ni mucho menos el primero ni el único programa con este fin. Un buen punto por donde empezar a conocer algún otro es Git: el programa utilizado actualmente para controlar las distintas versiones de kernel de Linux:

http://git.or.cz/


Mucha más información en la Wikipedia:

http://es.wikipedia.org/wiki/Control_de_versiones (español)
http://en.wikipedia.org/wiki/Version_control_system (inglés)


5. Agradecimientos

Este documento ha sido redactado para uso interno de mi departamento en mi trabajo y está publicado aquí con el conocimiento y la aprobación de mis jefes. Pues eso.

Un usuario menos

Como dice el refranero, no es lo mismo predicar que dar trigo. O lo que es lo mismo, hablar es muy fácil, pero no está de más que de vez en cuando los hechos acompañen a las palabras.

Hace unas semanas, el ordenador -Windows XP- de un familiar se había convertido en una granja de virus y diverso malware, así que había llegado el momento de limpiarlo o reinstalar el sistema operativo. Como da la casualidad que estamos en los días siguientes de la recentísima publicación de la versión definitiva de Ubuntu 8.04, decidí que era éste el que le iba a instalar, con la ventaja añadida de olvidar futuros problemas de virus y todo lo que conlleva un sistema Linux.

Llegué ufano y feliz con el CD todavía calentito e intenté arrancar sin modificar el sistema, ya sabéis, para ver si íbamos a tener problemas serios.. y el único problema es que cualquier cosa ridícula, como mover el ratón, suponía algunos minutos de rascar el CD. Y es que soy un animal -lo reconozco- porque pretendía exigir demasiado a un Athlon 2'4GHz con sólo 256MB de memoria. Alguien picajoso podría decir que eso tendría que avisarlo al arrancar, pero no era mi caso: yo estaba de lo más positivo.

Lo siguiente fue lanzarme a instalar el sistema a las bravas, sin encomendarme a nadie. El ordenador no tenía ningún archivo que tuviese que ser guardado -gracias sean dadas a GMail-, así que no me preocupó en lo más mínimo cosas como redimensionar particiones NTFS para no perder datos. Sencillamente me llevé por delante el sistema de archivos y utilicé todo el espacio para la nueva instalación. La velocidad no era la deseable, y cada uno de esos 7 pasos tardaba bastante en salir, pero insisto que en son 256MB -el mínimo que pide la instalación-.

Y por fin la instalación, y si has seguido mis peripecias con este acojosistema operativo seguro que ya te vas imaginando cómo termina la película. Porque la película termina con el ordenador frito cuando llega al 15% de la preparación de los discos duros, concretamente mientras calcula el sistema de archivos. No se muy bien qué estaba calculando, porque en el segundo intento configuré manualmente las particiones para que no se lo tuviese que pensar, pero volvió a quedarse muerto en el mismo punto.

Así que me gustaría que la historia hubiese terminado de otra forma, pero a estas alturas Ubuntu, y por extensión el mundo Linux, tiene un usuario menos de los que podría tener.


PD: Acabo de leer que hay una nueva versión de OpenSolaris. Quizá lo vuelva a intentar con el sistema operativo de una empresa seria.