¿Qué es un control de versiones?

Un control de versiones una herramienta para el desarrollo de software que facilita principalmente dos funciones:

  1. Ayuda a que varios programadores pueden trabajar en paralelo.
  2. Permite mantener varias versiones de un mismo programa a la vez. (De ahí “control de versiones”)

Trabajar en paralelo

Si dos programadores realizan cambios en un mismo fichero fuente, entonces sobreescriben los cambios del otro cada vez cuando lo guardan. Incluso si un equipo de trabajo llega a organizarse para que esto no sucede, todavía es probable que todos los “prints”, “ifs”, y demás modificaciones temporales que un programador pueda poner para probar su código molesten a los demás. Si el programa no compila entonces todos los demás están parados hasta que se haya arreglado el error.

Aquí ayuda un control de versiones. Los ficheros “buenos” – es decir una versión que al menos compila – están en un servidor, el “repositorio”. Un programador trabaja sobre una “vista” a estos ficheros (habitualmente una copia local en el ordenador del programador). Si quiere cambiar un fichero, entonces debe “sacarlo del control” (hacer un check-out o desproteger). Mientras tanto los demás programdores siguen viendo la versión original del fichero y no están afectados por las modificaciones de un miembro de equipo.

Cuando el primer programador cree que su versión modificada funciona razonablemente bien, entonces la “sube” (mete, hace un check-in o la protege). Con esto se ha creado una nueva versión, que será la que verá todo el mundo que “actualice su vista”. Un control de versiones no reemplaza a una copia de seguridad, porque no se guardan los cambios en el servidor hasta que el programador lo ordene. Y esto puede durar un mes en ocasiones.

Merge

Un control de versiones sólo permite “subir” un fichero, si es el sucesor de la versión de que fue sacado. Puede suceder que dos programadores sacan sus versiones personales de la misma versión. El primero puede hacer un check-in de sus cambios sin problemas, pero el segundo debe conciliar sus cambios con las modificaciones del otro programador. Un fichero sacado no se actualiza con las versiones que los otros programadores hayan metido, ya que sobreescribirían las modificaciones propias.

La solución es un “merge” (inglés para combinar). Habitualmente se abre una pantalla con las tres versiones afectados: La versión original de donde se partió, la versión a meter y la última versión bajo control. En un caso simple se ha modificado el fichero en puntos diferentes y se pueden simplemente incluir los cambios de la versión más reciente en la versión a meter. Dos cambios en una misma línea de código causan un “conflicto” que el programador debe resolver a su criterio y con la ayuda del otro programador. Muchas veces un control de versiones puede combinar versiones sin conflictos de forma automática. No es posible hacer un merge en ficheros binarios.

Mantener varias versiones

En muchos programas de uso común es habitual mantener varias versiones. Por ejemplo, no todo el mundo está dispuesto a instalar un nuevo sistema operativo cuando Microsoft publique una nueva versión de Windows. Así Microsoft debe mantener varias versiones de Microsoft Windows al mismo tiempo que está desarrollando la próxima generación.

¿Qué significa varias versiones? Cada vez cuando un programador sube sus cambios, se crea una nueva versión que el sistema enumera con un número secuencial. Podemos decidir que alguna de estas versiones, digamos la versión 3124, será destinada a ser una “release” oficial. Entonces se “etiqueta”, por ejemplo como “Windows 8 alpha” y se crea una nueva “rama” (branch en inglés). La rama principal (“trunk” en inglés) es la en que los programadores hagan el desarrollo nuevo. La rama “Windows 8 alpha” existe en paralelo y sirve para corregir los errores que todavía pueda tener. En esta versión interesa más llegar a una versión “estable”, un “release”, que añadir un nuevo desarrollo.

Lógicamente, todos los errores que se encuentran en la versión “Windows 8 alpha” habrá que corregir también en la rama de desarrollo principal. También puede suceder que alguna funcionalidad nueva de la rama de desarrollo entra en la rama de la versión “release”. En general, los programadores tienen que modificar varias versiones y el control de versiones les permite determinar cuales.

Como es imaginable, una rama de una release puede bifurcarse también. Una sigue con las correcciones de la versión (oficial) 8.0, la otra está destinada a incluir mejoras para la release 8.1. En el momento que una versión ya no incluirá nuevas funcionalidades se “congela”. Cuando ya no se trabaja sobre ella ya no está “soportada”.

Pequeña lista comentada de control de versiones

Hasta algunos años, la comunidad de código abierto ha usado con mucho gusto el CVS (Concurrent Versions System). Ahora se usa más el Subversion, que ofrece un cliente integrado en el explorador de Windows que se llama TurtoiseSVN. Es todo gratis y una buena solución para la mayoría de los proyectos.

Cuando gratis no es un requisito puede convenir usar IBM® Rational® ClearCase®, un programa completo que permite un uso por línea de comando y por interfaz gráfico. Microsoft Visual SourceSafe es un extra con las versiones de empresa de Visual Studio, pero que a veces da impresión de ser ni visual ni seguro. La ventaja que tiene es que se integra bien con el Visual Studio.

Quien piensa en grade debe tener en cuenta que eligir una herramienta de control de versiones es una decisión estratégica de la empresa. Una base de datos es lo más difícil de actualizar en un programa y un control de versiones no es otra cosa que una base de datos donde los datos son ficheros. Es bastante probable que una empresa todavía usa el control de versiones de hoy en diez años.

Anuncios