Álvaro J. Iradier

Si Satanás se reencarnara en la tierra en forma de empresa de Software y decidiera desarrollar un sistema de control de versiones para regocijarse en el dolor y el sufrimiento de los programadores y traer el caos, desgracia y destrucción a toda la humanidad, sin duda llamaría a esta aplicación Visual SourceSafe, o VSS para los amigos. El control de código fuente convertido en el infierno, y el alma de los desarrolladores ardiendo en el fuego eterno.

Para los neófitos en el tema, un sistema de control de código fuente permite que un equipo de desarrolladores trabaje en paralelo sobre un conjunto de archivos de código, almacenado en un repositorio, manteniendo un histórico de las versiones de los archivos. Esto nos permite hacer un seguimiento de los cambios que se han producido, y volver atrás en cualquier momento. Otras opciones más avanzadas permiten crear ramas de desarrollo, en las que un proyecto se bifurca en distintas versiones, que pueden posteriormente volverse a unir.

Antes de trabajar con VSS había trabajado con CVS y con Subversion. A pesar de algunas carencias importantes de CVS, debido fundamentalmente a su antiguedad, en funcionamiento desde 1986, lo considero un sistema superior a VSS. Subversion soluciona la mayoría de los problemas de CVS, y además simplifica la sintáxis de los comandos. Es una maravilla. En cualquier caso, existen aplicaciones como TortoiseCVS y TortoiseSVN que integran CVS y Subversion respectivamente con el explorador de Windows, o AnkhSVN que integra Subversion con Visual Studio. Los usuarios de Linux normalmente no necesitan tantas facilidades, y saben buscarlas por su cuenta, por lo que no me molestaré en poner enlaces.

VSS contradice uno de los principios fundamentales de un buen sistema de versiones, que es el trabajo en paralelo. La forma de trabajar de VSS nos obliga a bloquear un archivo ("Check Out" o "Desproteger") antes de poder trabajar con él. Mientras un archivo está protegido, ningún usuario puede subir cambios a este. En teoría uno puede trabajar de forma local sin desproteger el archivo, y luego mezclarlo (Merge) con el archivo del repositorio, una vez que éste quede libre, pero se puede denominar esta operación como de máximo riesgo.

Por un lado, VSS insiste de forma continuada en sobreescribir nuestra copia local y modificada del archivo a cada intento que hacemos de desproteger el archivo. Cualquier pequeño descuido hará que todo el cuidadoso trabajo invertido en nuestro código se vaya al traste para siempre. Si conseguimos superar esta fase, y procedemos a la operación de mezclado, VSS nos presenta un proceso totalmente manual y con un interfaz poco intuitivo, para que, diferencia por diferencia, decidamos cual de las dos versiones (la del repositorio, o la local) se incluye en el resultado final.

Para ayudar un poco más a este caos, algunas implementaciones de VSS como el plugin de Eclipse tienen el comportamiento curioso de no recargar el archivo si este estaba abierto al desprotegerlo. El resultado es que una vez desprotegido el archivo, al guardarlo será sobreescrito por nuestra versión local, que no incorporará los cambios descargados del repositorio.

Si alguien piensa que tal vez VSS subsana las carencias de CVS, como el no permitir renombrar archivos o carpetas, está equivocado. Satán es muy meticuloso con su trabajo, y cuando un archivo se renombra se pierde todo el historial.

No podemos cerrar este artículo sin comentar otra de las features de VSS: la corrupción de datos. VSS basa su almacenamiento en una base de datos Access, motor de base de datos profesional como ninguno. Si durante alguna operación tan trivial como la descarga de la última versión de los archivos se produce una interrupción, SourceSafe nos avisará de que el administrador del repositorio debería utilizar la herramienta de análisis y reparación para evitar corrupción. Y creanme, deberían hacerlo. Lo habitual es pasarla al menos una vez a la semana si no queremos llorar después. Quedan avisados.