Durante el desarrollo de cualquier producto, no solamente del código de un programa, éste evoluciona mientras se realizan sucesivos cambios en él. Sin ir más lejos, un libro no se escribe entero en un par de horas sino que se prolonga durante un número de sesiones indeterminadas durante las cuales se añade más y más contenido. Esta adición de contenido realmente son cambios sucesivos al documento. Evidentemente, no todos los cambios consisten en adicciones sino que muchas veces se modifican o eliminan partes ya existentes por diversos motivos.
Generalmente cuando se están desarrollando proyectos ya sean pequeños o grandes se tiene como mínimo la participación de dos desarrolladores, esto hace que se trabaje en diferentes módulos del proyecto que luego de manera manual serán pegadas las partes, sin embargo si el grupo de desarrolladores va creciendo el modo de pegar las partes creadas por cada programador se vuelve bien difícil y complicada, es por eso que a lo largo de los años se han desarrollado diferentes herramientas que permiten llevar un control de las distintas versiones de los proyectos, donde se permite gestionar de una manera más organizada los repositorios de archivos y sus distintas versiones, utilizando una arquitectura cliente-servidor, donde un servidor guarda las versiones actuales del proyecto y su historia, todo esto dependiendo de las cambios y actualizaciones que haga el desarrollador. Independientemente del tipo de cambio realizado, los cambios no son siempre definitivos ni correctos. En muchos casos, un cambio introduce un error que es corregido con cambios posteriores pero, en algunos casos, se desearía poder deshacer completamente un cambio erróneo. En estas circunstancias es cuando interviene los programas de gestión de versiones.
Mediante los procesos definidos de estos sistemas, es posible trazar los cambios que se han realizado en el tiempo. Al disponer de esta información, es posible identificar y controlar todos y cada uno de los cambios realizados. Asimismo, es posible regenerar sin errores el estado del producto en cualquier momento de su desarrollo, es decir, cualquiera de sus versiones, además nos da una serie de ventajas, ya que permite que varios clientes pueden sacar copias del proyecto al mismo tiempo, realizar cambios a los ficheros manteniendo un histórico de los cambios, deshacer los cambios hechos en un momento dado y recuperar versiones pasadas así evitando posibles errores que ocurran en un proceso de actualización, también permiten ver un histórico de cambios y comentarios, lo cual permite que los clientes pueden también comparar diferentes versiones de archivos.
Llevar este control puede parecer complejo en un inicio pero simplifica enormemente el trabajo a corto plazo. Una vez implantado se transforma en una herramienta indispensable de trabajo.
Todos los sistemas de control de versiones se basan en el concepto repositorio. Un repositorio no es más que el conjunto de versiones del producto. Una vez creado, los distintos usuarios realizan sus cambios sobre el repositorio que se encarga de almacenarlos permitiendo la recuperación de cualquier versión.
Existen dos tipos de repositorios:
CentralizadoCuando se desarrollaron los sistemas de control de versiones, muchos de ellos se hicieron en esquema cliente-servidor, con lo que el desarrollo de las herramientas está claramente diferenciado entre:
•El cliente: Es la aplicación que se conecta al servidor y mantiene una copia local del repositorio, así como se encarga, generalmente de la corrección de conflictos y la mayoría de lógica del sistema.
•El servidor: Es el sistema que toma los datos del cliente y los almacena a espera de una o múltiples peticiones de esos datos. Este sistema se encargaría del almacenamiento de las versiones, control de concurrencia, bloqueos y otras características parecidas a las de las bases de datos.
¿Qué limitaciones y características posee?
•El sistema servidor es un repositorio, como los que mantienen los clientes, pero perfectamente sincronizado y sin que dé lugar a conflictos. Es la copia maestra de los datos.
•Cuando un sistema web quiere hacer un listado, puede tomar los datos de este servidor y siempre serán seguros, con lo que no tendrá que resolver conflictos, ni tendrá que hacer mezclas.
•Una copia local debe de poder mezclarse con el repositorio central cuando queramos publicar un conjunto de cambios o cuando queramos tomar la última versión publicada en concordancia con nuestra copia local.
•Es normal ver en muchos de estos sistemas ramificaciones, versiones, etiquetas, o similares, a modo de tener varias copias según nos interese. Estas ramificaciones están en el servidor y en algunos casos puede llegar a ser muy costosa su diferenciación.
Algunos ejemplos de Controladores de Versiones Centralizados:
•Concurrent Versions System (CVS)
•SubVersion
DistribuidoDesarrolladores como Linus Torvalds, Eric S. Raymond y otros más, han desarrollado sistemas distribuidos de control de versiones tales como GIT, Baazaar, Mercurial, darcs, entre otros; estos sistemas se destacan por haber sido desarrollados en un formato distribuido, esto quiere decir que, en sí, no hay un servidor que mantenga una copia del repositorio, sino que está mantenida entre los clientes que estén en uso del repositorio y, al igual que los clientes P2P, mientras más desarrolladores haya conectados, mejor conectividad habrá entre todos.
En cualquiera de los dos casos, el repositorio es compartido por todos los usuarios (o al mismo usuario desde distintas máquinas) que tengan acceso al mismo. Es posible que se produzcan ediciones simultáneas de los mismos elementos que generen conflictos. Para solucionar este problema existen dos políticas básicas de resolución de conflictos:
Bloqueo-modificación-desbloqueo:En esta política se evitan las modificaciones concurrentes. Cuando un usuario desea realizar una modificación, indica el elemento a modificar que queda bloqueado en el repositorio por lo que se impide el acceso al resto de usuarios (exclusión mutua). Cuando finaliza de realizar sus cambios, los envía al repositorio liberando el bloqueo con lo que el resto de los usuarios puede obtener la copia actualizada para realizar sus propios cambios.
Copiar-modificar-mezclar:Esta política permite las modificaciones simultáneas. Cada usuario hace una copia del repositorio en su máquina y procede trabajar con ella como si no fuera un repositorio. Cuando finaliza su trabajo, envía los cambios al repositorio que se encarga de analizar los cambios realizados por el usuario y los que se han realizado en el propio repositorio y realiza la mezcla.
Evidentemente, la primera política es mucho más restrictiva lo que dificulta el trabajo diario ralentizando el acceso a los recursos y ocasionando problemas si no se liberan recursos bloqueados. La segunda, por su parte, tiene como inconveniente que no siempre es posible mezclar los cambios realizados aunque en esos casos, utiliza al usuario que envía cambios para solucionar esos conflictos irresolubles automáticamente.
Esto da una serie de ventajas al sistema centralizado, como son:
•Disponer de forma distribuida de la información del repositorio al completo, tanto de forma local, como a través de los demás componentes del grupo.
•Cada cambio se va replicando entre los demás equipos distribuidos, a modo de que puedan emplear esos datos y actualizarlos en sus sistemas.
•El sistema de control de versiones distribuido ha sido pensado con la forma de trabajo basada en ramas, unión central en una sola versión (trunk) y liberaciones (o tags). Con lo que cada rama puede identificarse como cada copia distribuida que se use.
•Una máquina servidora puede emplearse, al estar siempre conectada, como otro punto de sincronización, con la ventaja de que, aunque cayera, mientras haya más miembros conectados, el sistema siempre se mantiene activo y con buen ancho de banda.
Algunos ejemplos de Controladores de Versiones Distribuidos:
•Baazaar
•Mercurial
•GIT
