Entornos de Desarrollo

UD 3 Control de versiones

1
Introducción 3
Concepto 3
Componentes de un sistema de control de versiones 5
Clasificación de los sistemas de control de versiones 6
Sistemas locales 7

Sistemas centralizados 8

Sistemas distribuidos 8
Operaciones básicas de un sistema de control de versiones 9
Herramientas de control de versiones 10
Otras herramientas 11
Depósitos de herramientas de control de versiones 12
Problemáticas de los sistemas de control de versiones 13
Compartir archivos por parte de diferentes programadores 13

Bloquear los archivos utilizados 14

Fusionar los archivos modificados 15

2
Introducción
Una vez conocidas algunas herramientas para documentar los programas y herramientas para refactorizar, el
objetivo es que conozcáis y manejéis herramientas de control de versiones. El uso de este tipo de herramientas
asegura por un lado que los proyectos mantengan una trazabilidad de todos los cambios que han sufrido a lo largo
de su vida, y quién o quiénes han realizado los cambios, cuestión de vital importancia cuando se trabaja en equipos
de software.
Así pues, para un trabajo que no empieza y acaba dentro de un periodo corto de tiempo, o para trabajos que
tienen que ser desarrollados por un equipo de personas, es recomendable tener un control de las tareas que se
han hecho, cuando se han llevado a cabo, quién las ha hecho...
Se habla de gestión de proyectos cuando se tiene que desarrollar un trabajo como el que se acaba de definir y,
además, se planifica. ¿Qué tiene que ver la gestión de proyectos con el control de versiones de un software que
se está́ desarrollando? Tendrá mucho que ver la analogía que tienen los dos procedimientos. Si el trabajo pedido
es el cambio de la fuente de alimentación de un ordenador, no hará falta ni planificarlo ni, probablemente, en
caso de que se deje el trabajo a medias, habrá que dejar documentada la situación en que se encuentra el trabajo
en cuestión. En cambio, si un único programador tiene que implementar una calculadora, será discutible decidir
si necesitará una planificación y una gestión de este trabajo como si fuera un proyecto (planificando, analizando,
diseñando y desarrollando) o si necesitará una herramienta que gestione las versiones desarrolladas hasta el
momento. Quizás llevar un control de versiones del software desarrollado le servirá para poder volver atrás en
caso de llegar a un punto de no retorno. ¿Cuándo es muy recomendable utilizar un control de versiones? En
casos en que el desarrollo de software comporta un trabajo de muchas horas, de muchos ficheros diferentes y
(aunque no necesariamente) la presencia de varias personas trabajando sobre el mismo proyecto, como por
ejemplo en el desarrollo de un ERP (Enterprise Resource Planning).

Concepto
Se puede definir control de versiones como la capacidad de recordar todos los cambios que se realizan tanto en
la estructura de directorios como en el contenido de los archivos. Esto es de mucha utilidad cuando se desea
recuperar un documento, o una carpeta, o un proyecto en un momento concreto de su desarrollo. También es
muy útil cuando se necesita mantener un cierto control de los cambios que se realizan sobre documentos, archivos
o proyectos que comparten varias personas o un equipo de trabajo, se hace necesario saber qué cambios se hacen,
quién los hace y cuándo se realizan.

Un sistema de control de versiones es una herramienta de ayuda al desarrollo de software que irá almacenando,
según los parámetros indicados, la situación del código fuente en momentos determinados. Es como una
herramienta que va tirando fotos de forma regular, cada cierto tiempo, sobre el estado del código.

En un entorno donde solo trabajará un programador, solo habrá que guardar la información del código cada
cierto tiempo o cada vez que se guarde la información, junto con los datos principales, como por ejemplo el
número de la versión o la fecha y la hora en que se ha almacenado. En un entorno multiusuario, donde muchos
programadores diferentes pueden manipular los ficheros y donde, incluso, se podrá ofrecer la posibilidad de
modificar a la vez un mismo documento, en estos casos hay que almacenar mucha más información, como por

3
ejemplo qué usuario ha implementado los cambios, las referencias de la máquina desde donde se han hecho los
cambios, si se está produciendo algún tipo de conflicto, etc...

Esta funcionalidad no solo será importante en los casos de desarrollo de software, sino también en muy otros
ámbitos. Por poner algunos ejemplos, se puede encontrar la importancia del control de versiones en el caso de
trabajar en la creación de un libro, colaborando varios autores en su redacción. Si queda grabado en qué momento
ha hecho cada cambio cualquiera colaborador diferente, y, además, queda grabada una copia de cada
modificación hecha, esto permitirá al resto de colaboradores tener una información muy importante para no
repetir contenidos ni duplicar trabajos. Un ejemplo real para el que se acaba de explicar se puede encontrar en
la redacción de contenidos de la Wikipedia, donde muchos redactores crean contenidos mediante una
herramienta que permite el trabajo en equipo y el control de los contenidos creados y colgados. Otro caso se
puede encontrar en una gestoría o un bufete de abogados que tienen que redactar un contrato o un documento
en colaboración con uno o varios clientes. En este caso, no será necesario usar una herramienta como una wiki,
quizás será suficiente usar un buen editor de textos que permita la funcionalidad de gestión de cambios, donde
cada vez que un usuario diferente tenga que hacer un cambio, quede indicado en el documento con un color
diferente en función del usuario que lo haya creado. En el desarrollo de software, los sistemas de control de
versiones son herramientas que pueden facilitar mucho el trabajo de los programadores y aumentar la
productividad de forma considerable, siempre que estas herramientas sean utilizadas de forma correcta. Algunas
funcionalidades de los sistemas de control de versiones pueden ser:

• Comparar cambios en los diferentes archivos a lo largo del tiempo, pudiendo ver quién ha modificado
por última vez un determinado archivo o trozo de código fuente.

• Reducción de problemas de coordinación que puede haber entre los diferentes programadores. Con los
sistemas de control de versiones podrán compartir su trabajo, ofreciendo las últimas versiones del código
o de los documentos, y trabajar, incluso, de forma simultánea sin miedo a encontrarse con conflictos en
el resultado de esta colaboración.

• Posibilidad de acceder a versiones anteriores de los documentos o código fuente. De forma programada
se podrá automatizar la generación de copias de seguridad o, incluso, almacenar todo cambio efectuado.
En el caso de equivocación de forma puntual, o durante un periodo largo de tiempo, el programador
podrá tener acceso a versiones anteriores del código o deshacer, paso a paso, todo aquello desarrollado
durante los últimos días.

• Ver qué programador ha sido el último en modificar un determinado trozo de código que puede estar
causando un problema.

• Acceso al historial de cambios sobre todos los archivos a medida que avanza el proyecto. También puede
servir para el jefe de proyectos o para cualquier otra parte interesada (stakeholder), con permisos para
acceder a este historial, para ver la evolución del proyecto.

• Volver un archivo determinado o todo el proyecto entero a uno o en varios estados anteriores.
Los sistemas de control de versiones ofrecen, además, algunas funcionalidades para poder gestionar un proyecto
informático y para poder hacer el seguimiento. Entre estas funcionalidades se pueden encontrar:

• Control histórico detallado de cada archivo. Permite almacenar toda la información de lo que ha sucedido
en un archivo, como por ejemplo todos los cambios que se han efectuado, por quienes, el motivo de los
cambios, almacenar todas las versiones que ha habido desde su creación...

• Control de usuarios con permisos para acceder a los archivos. Cada usuario tendrá un tipo de acceso
determinado a los archivos para poder consultarlos o modificarlos o, incluso, borrarlos o crear nuevos.

4
 Este control tiene que ser gestionado por la herramienta de control de versiones, almacenando todos los
usuarios posibles y los permisos que tienen asignados.

• Creación de ramas de un mismo proyecto: en el desarrollo de un proyecto hay momentos en que hay
que ramificarlo, es decir, a partir de un determinado momento, de un determinado punto, hay que crear
dos ramas del proyecto que se podrán continuar desarrollando por separado. Este caso se puede dar en
el momento de finalizar una primera versión de una aplicación que se entrega a los clientes, pero que hay
que continuar evolucionando.

• Fusionar dos versiones de un mismo archivo: permitiendo fusionarlas, cogiendo, de cada parte del
archivo, el código que más interese a los desarrolladores. Esta funcionalidad se tendrá que validar
manualmente por parte de una persona.

Componentes de un sistema de control de versiones

Un sistema de control de versiones se compondrá de varios elementos o componentes que usan una terminología
un poco específica. A continuación, quedan definidos algunos de estos elementos:

• Repositorio: conjunto de datos almacenados, también referido a versiones o copias de seguridad. Es el

lugar donde estos datos y cambios quedan almacenadas. Puede ser un sistema de archivos en un disco
duro, un banco de datos, un servidor, etc... Se podrá referir a muchas versiones de un único proyecto o
de varios proyectos

• Módulo: se refiere en una carpeta o directorio específico del repositorio. Un módulo podrá hacer
referencia a todo el proyecto entero o solo a una parte del proyecto, es decir, a un conjunto de archivos.

• Revisión o versión: es cada una de las versiones almacenadas de un determinado proyecto; podrá hacer
referencia a todos los archivos de un proyecto que componen una versión determinada en un instante de
tiempo o a los archivos que han sido modificados desde la última versión. Algunos sistemas identifican
las revisiones con un número contador (como Subversion). Otros identifican las revisiones mediante un
código de detección de modificaciones (Git usa SHA1). La última versión se la identifica como la cabeza
o HEAD.

• Etiquetar o rotular (tag): información que se añadirá a un módulo para indicar alguna característica
específica que lo hace especial. Esta información será textual y, muchas veces, se hará de forma manual.
También podrá utilizarse para localizar un conjunto de ficheros que componen una revisión completa y
que se quieren tener localizados o para poder referenciar desde otra versión. Cuando se crea una versión
concreta en un momento determinado del desarrollo de un proyecto se le pone una etiqueta, de forma
que se pueda localizar y recuperar en cualquier momento. Las etiquetas permiten identificar de forma
fácil revisiones importantes en el proyecto.

• Tronco (trunk): es el tronco o la línea principal de desarrollo de un proyecto.

• Rama: se usará para llevar a cabo un análisis de las revisiones almacenadas sin afectar las revisiones en
curso. Para conseguir esto, hay que hacer una copia de un módulo o una revisión entera para poder
trabajar en paralelo. A esta copia se lo denominará rama. En otras palabras, son copias de archivos,
carpetas o proyectos. Cuando se crea una rama se crea una bifurcación del proyecto y se crean dos líneas

5
 de desarrollo. Son motivos habituales de creación de ramas la creación de nuevas funcionalidades o la
corrección de errores.

• Desplegar (checkout): crear una copia de trabajo del proyecto, o de archivos y carpetas del repositorio
en el equipo local. Por defecto se obtiene la última versión, aunque también se puede indicar una versión
concreta. Con el checkout se vincula la carpeta de trabajo del equipo local con el repositorio, y se crean
los metadatos de control de versiones.

• Confirmar (commit o check-in): se realiza commit cuando se confirman los cambios realizados en local
para integrarlos al repositorio.

• Exportación (export): similar al checkout, pero sin vincular la copia con el repositorio. Es una copia
limpia sin los metadatos de control de versiones.

• Importación (import): es la subida de carpetas y archivos del equipo local al repositorio. Se puede hacer
en cualquier momento desde el sistema de archivos.

• Actualizar (update): Se realiza una actualización cuando se desea integrar los cambios realizados en el
repositorio en la copia de trabajo local.

• Fusión (merge): una fusión consiste en unir los cambios realizados sobre uno o varios archivos en una
única revisión. Se suele realizar cuando hay varias líneas de desarrollo separadas en ramas y en alguna
etapa se necesitan fusionar los cambios hechos entre ramas o en una rama con el tronco principal, o
viceversa.

• Conflicto: ocurre cuando dos usuarios crean una copia en local (checkout) de la misma versión de un
archivo, uno de ellos realiza cambios y envía los cambios (commit) al repositorio, y el otro no actualiza
(update) esos cambios y realiza cambios sobre el archivo e intenta enviar luego sus cambios al repositorio.
Entonces se produce el conflicto y el sistema no es capaz de fusionar los cambios. Este usuario deberá
resolver el conflicto combinando los cambios o eligiendo uno de ellos.

• Resolver conflicto: la actuación del usuario para atender un conflicto entre diferentes cambios al mismo
documento.
Para trabajar en proyectos utilizando un sistema de control de versiones, lo primero que hay que hacer es crearse
una copia en local de la información del repositorio con checkout, de esta manera se vincula la copia con el
repositorio, a continuación, el usuario realizará sus modificaciones y una vez finalizadas sube las modificaciones
al repositorio con commit. Si la copia de la usuaria ya está vinculada al repositorio, antes de modificar y realizar
cambios tiene que hacer update, para asegurarse que los cambios se realizan sobre la última versión del
repositorio.

Clasificación de los sistemas de control de versiones

Se puede generalizar la estructura de las herramientas de control de versiones teniendo en cuenta la clasificación
de los sistemas de control de versiones, que pueden ser locales, centralizados o distribuidos.

6
Sistemas locales
Los sistemas de control de versiones locales son sistemas que permiten llevar a cabo las acciones necesarias de
forma local. Si no se usa ningún sistema de control de versiones concreto, un programador que trabaje en su
propio ordenador podrá ir tirando copias de seguridad, de vez en cuando, de los archivos o de las carpetas con
que trabaje. Este sistema implica dos características específicas:

• El mismo programador será la persona que deberá recordar de ir tirando las copias de seguridad cada
cierto tiempo, el que él haya establecido.

• El mismo programador tendrá que decidir donde llevará a cabo estas copias de seguridad, muy
probablemente en local, en otra ubicación del disco duro interno, o en un dispositivo de almacenamiento
externo.
Este sistema tiene un alto riesgo porque es un sistema altamente dependiente del programador, pero es un sistema
extremadamente sencillo de planificar y de ejecutar. Lo más habitual, en estos casos, es crear copias de seguridad
(que se pueden considerar versiones del proyecto); los ficheros se almacenan en carpetas que suelen tener un
nombre representativo, como, por ejemplo: la fecha y la hora en que se efectúa la copia. Pero, tal como se ha
comentado anteriormente, se trata de un sistema propenso a errores por varios motivos, como por ejemplo que
se produzcan olvidos en la realización de la copia de seguridad, o confusiones que lleven al programador a
continuar el desarrollo en una de las copias del código, e ir avanzando con el proyecto en diferentes ubicaciones
diferentes días.

Para hacer frente a estos problemas, aparecieron los primeros repositorios de versiones que contenían una
pequeña base de datos donde se podían grabar todos los cambios efectuados, sobre qué archivos, quién los había
hecho, cuándo... Efectuando las copias de seguridad de forma automatizada.

7
Sistemas centralizados
Un sistema de control de versiones que permita desarrollar un proyecto informático con más de un ordenador
es el sistema de control de versiones centralizado que se contrapone a otro sistema de control de versiones,
también para más de un ordenador, como es el distribuido.
En los sistemas centralizados habrá más de un programador desarrollando un proyecto en más de un ordenador.
Desde los dos ordenadores se podrá acceder a los mismos archivos de trabajo y sobre las mismas versiones
almacenadas. Esta es una situación más próxima a las situaciones actuales reales en el desarrollo de proyectos
informáticos.
El sistema de control de versiones centralizado es un sistema donde las copias de seguridad o versiones
almacenadas se encuentran de forma centralizada a un servidor que será accesible desde cualquier ordenador
que trabaje en el proyecto.

Pero este sistema también tendrá sus inconvenientes, a veces muy difíciles de salvar. ¿Qué sucede si falla el
servidor central? Si es un fallo temporal no se podrá acceder durante un pequeño periodo tiempo. Si es un fallo
del sistema, habrá que tener preparado un sistema de recuperación o un sistema alternativo (una copia). Durante
este tiempo, los diferentes desarrolladores no podrán trabajar de forma colaborativa ni acceder a las versiones
almacenadas ni almacenar de nuevas. Este es una desventaja difícil de contrarrestar.
Como que el repositorio se encuentra centralizado en un único ordenador y una única ubicación, la creación de
una rama se llevará a cabo en la misma ubicación que el resto del repositorio, utilizando una nueva carpeta para
crear la duplicidad. Los puntos débiles con el trabajo de las ramas serán los mismos que se han expuesto en
general para los sistemas de control de versiones centralizados.

Sistemas distribuidos
Los sistemas de control de versiones distribuidos ofrecen una solución a esta desventaja ofrecida por los sistemas
de control de versiones centralizados. La solución que ofrecen los sistemas distribuidos es disponer cada
ordenador de trabajo, así como el servidor, de una copia de las versiones almacenadas. Esta duplicidad de las

8
versiones ofrece una disponibilidad que disminuye muchísimo las posibilidades de no tener accesibilidad a los
archivos y a sus versiones.

¿Cuál es la forma de trabajar de este sistema? Cada vez que un ordenador cliente accede al servidor para tener
acceso a una versión anterior, no solo copian aquel archivo, sino que hacen una descarga completa de los archivos
almacenados. Si el servidor tiene un fallo del sistema, el resto de ordenadores clientes podrán continuar
trabajando y cualquiera de los ordenadores clientes podrá efectuar una copia entera de todo el sistema de
versiones hacia el servidor para restaurarlo. La idea es que el servidor es el que gestiona el sistema de versiones,
pero en caso de necesidad puede acceder a las copias locales que se encuentran en los ordenadores clientes.

Operaciones básicas de un sistema de control de versiones

Entre las operaciones más habituales de un sistema de control de versiones (tanto en los sistemas centralizados
como en los distribuidos) se pueden diferenciar dos tipos: aquellas que permiten la entrada de datos al repositorio
y aquellas que permiten obtener datos del repositorio.

9
Entre las operaciones de introducción de datos al repositorio se pueden encontrar:

• Importación de datos: esta operación permite llevar a cabo la primera copia de seguridad o versionado
de los archivos con los cuales se trabajará en local hacia el repositorio.

• Confirmar (commit): esta operación permite enviar, al repositorio, los datos correspondientes a los
cambios que se han producido en el servidor local. No se hará una copia entera de toda la información,
sino que solo se trabajará con los archivos que se hayan modificado en el último espacio de tiempo.

Entre las operaciones de exportación de datos del repositorio se pueden encontrar:

• Desplegar (checkout): con esta operación se podrá tener acceso y descargar una versión de trabajo de un
archivo, un módulo o una revisión a un ordenador cliente.

• Actualización (update): esta operación permite llevar a cabo una copia de seguridad de todos los datos
del repositorio al ordenador cliente con que trabajará el programador. Será una operación que se podrá
efectuar de forma manual, cuando el programador lo estime oportuno, o de forma automática, como en
los sistemas distribuidos, donde cada vez que un cliente accede al repositorio se hace una copia completa
en local.

Herramientas de control de
versiones
Para llevar a cabo un control de versiones automatizado existen varias herramientas que facilitan mucho este
trabajo. Estas herramientas pueden ser independientes al resto de herramientas que se usarán para la gestión y el
desarrollo del proyecto informático o se pueden encontrar integradas con otras herramientas, como por ejemplo
Visual Studio o Eclipse, facilitando así el trabajo de los miembros del equipo del proyecto. Las funcionalidades
que ofrecen pueden ir desde el control del código fuente, la configuración y gestión del cambio, la administración
de versiones de archivos y de directorios de un proyecto, hasta la integración completa de los proyectos,
analizando, planificando, compilando, ejecutando y probando de forma automática los proyectos.

10
Algunas herramientas de control de versiones son:

• Team Foundation Server. Esta herramienta ha sido desarrollada por Microsoft, cosa que implica que sea
una herramienta privativa. Es una herramienta preparada para trabajar en colaboración con Visual Studio
2010. Permite acciones de control de código, administración del proyecto, seguimiento de los elementos
de trabajo y gestión de los archivos a partir de un portal web del proyecto. Se trata de una evolución de
la herramienta Visual Source Safe.

• CVS - Concurrent Versions System. Esta herramienta ofrece un sistema de control de versiones con una
serie de funcionalidades que ayudan el programador:
▪ Mantenimiento del registro de todo el trabajo por parte de los miembros del equipo del proyecto.
▪ Grabación de todos los cambios en los ficheros.
▪ Permiteeltrabajoenequipoencolaboraciónporpartededesarrolladoresa gran distancia.

• Subversion. Herramienta de Código Abierto, independiente del sistema operativo de la máquina en que
se utilice. Herramienta desarrollada en 2000 con el objetivo de sustituir a CVS. Añade nuevas
funcionalidades y mejora algunas otras que no acababan de funcionar adecuadamente con la herramienta
CVS. Disponible para varios sistemas operativos, como la distribución RedHat, MacOS...

• MyLyn. Herramienta de control de versiones que es una extensión de lo IDE Eclipse. Permite tanto la
gestión del proyecto como la gestión de las versiones. Disponible para Linux y MacOs X.

• Git. Herramienta de Gestión de Versiones desarrollada para programadores del núcleo de Linux.
Desarrollada a partir de evoluciones de la herramienta CVS, puesto que Subversion no cubría las
necesidades de los desarrolladores de proyectos Linux.

Otras herramientas
Existen otras muchas herramientas para la ayuda del control de versiones. Algunas se pueden clasificar en función
del lenguaje de programación al que asisten y otros se pueden clasificar en función del o de los sistemas para qué
fueron desarrolladas. Podéis ver a continuación otras herramientas de sistema de gestión de versiones, clasificadas
en función de si pertenecen a software libre o privativo:

• Software libre:
▪ GNU Arch
▪ RedMine
▪ Mercurial (ALSA, MoinMoin, Mutt, Xen) o PHPCollab
▪ Git
▪ Mylyn
▪ CVS
▪ Subversion
• Software privativo: o Clear Case
▪ Darcs
▪ TeamFundationServer

11
 Depósitos de herramientas de control de versiones
Un depósito es un almacén de datos donde se guardará todo aquello relacionado con una aplicación
informática o unos datos determinados de un determinado proyecto.

El uso de depósitos no es una técnica exclusiva de las herramientas de control de versiones. Las aplicaciones y
los proyectos informáticos suelen usar depósitos que contienen información. Por ejemplo, un depósito con
información en lo referente a una base de datos contendrá todo lo referente a cómo está implementada esta base
de datos: qué tablas tendrá, qué campos, cómo serán estos campos, sus características, sus valores límites...

En el ámbito del control de versiones, tener este depósito supone poder contar con un almacén central de datos
que guarda toda la información en forma de ficheros y de directorios, y que permite llevar a cabo una gestión de
esta información.
Toda herramienta de control de versiones tiene un repositorio que es utilizado como un almacén central de datos.
La información almacenada será todo lo referente al proyecto informático que se estará desarrollando. Los
clientes se conectarán a este repositorio para leer o escribir esta información, accediendo a información otros
clientes o haciendo pública su propia información.

Gracias a la información grabada en el repositorio se podrá:

• Consultar la última versión de los archivos que se hayan almacenado.

• Acceder a la versión de un determinado día y compararla con el actual.
• Consultar quién ha modificado un determinado trozo de código y cuando fue modificado.

Un repositorio es la parte principal de un sistema de control de versiones. Son sistemas diseñados para grabar,
guardar y gestionar todos los cambios e informaciones sobre todos los datos de un proyecto a lo largo del
tiempo.

12
 Problemáticas de los sistemas de control de versiones
Los sistemas de control de versiones tienen que resolver ciertas problemáticas, como, por ejemplo, cómo evitar
que las acciones de un programador se sobrepongan a los otros programadores. Contamos con diferentes
alternativas para resolver estas problemáticas:

• Compartir archivos por parte de diferentes programadores

• Bloquear los archivos utilizados
• Fusionar los archivos modificados

Compartir archivos por parte de diferentes programadores

Dos compañeros que trabajan en el mismo proyecto, desarrollando una aplicación informática, deciden editar el
mismo fichero del repositorio a la vez. Por ejemplo:

• Pau y Montse están editando un mismo fichero.

• Pau graba sus cambios al repositorio.
• Como Pau y Montse han accedido a la vez, la versión sobre la cual Montse trabaja no contendrá los
cambios efectuados por Pau.
• Montse podrá, accidentalmente, sobrescribirlos con su nueva versión del archivo, por el hecho de ser la
última persona que los guarda. Los cambios de Pau no se encuentran en la nueva versión de Montse.
• La versión del archivo de Pau no se ha perdido para siempre (porque el sistema recuerda cada cambio).
• El resto de programadores que accedan al repositorio verán la nueva versión de Montse, pero no podrán
ver los cambios de Pau a no ser que indaguen en el histórico del archivo.
El trabajo de Pau se habrá obviado, cosa que se tiene que evitar que se produzca. Por eso existen varias soluciones
que ofrecen las herramientas de control de versiones.

13
Bloquear los archivos utilizados
El caso expuesto anteriormente se puede prevenir utilizando alguna de las técnicas que ofrecen las herramientas
de control de versiones. Muchos de estos sistemas utilizan un modelo de solución que consiste a bloquear los
archivos afectados cuando un usuario está accediendo en modo modificación. La secuencia seria:

• Bloquear el archivo a que se quiere acceder.

• Modificar el archivo por parte del usuario.
• Desbloquear el archivo una vez modificado y actualizado al repositorio.

Se trata de una solución sencilla tanto conceptualmente como de implementación. Pero tiene algunos puntos no
tan positivos. En primer lugar, solo permite acceder a la modificación de un archivo a un único usuario. En el
caso planteado, Pau podrá acceder al archivo para consultar y modificar, pero Montse no podrá acceder, puesto
que Pau lo tendrá bloqueado. Se tendrá que esperar que Pau lo acabe de modificar para desbloquearlo y,
entonces, podrá acceder ella. Se trata de una solución muy restrictiva que puede afectar negativamente el trabajo
de los desarrolladores.

Algunos problemas de esta solución de bloqueo de archivos son:

• Posible creación de inconsistencias. Puede parecer que utilizando el sistema de los bloqueos haya más
seguridad a la hora de manipular archivos, pero puede darse el caso contrario. Si Pau bloquea y edita el
archivo A, mientras Montse simultáneamente bloquea y edita el archivo B, pero los cambios que hacen
no tienen en cuenta los cambios del otro desarrollador, se puede dar una situación en que, al dejar de

14
 bloquear los archivos, los cambios hechos a cada uno sean semánticamente incompatibles. Es decir, A y
B ya no funcionan juntos.

• Mientras un usuario, por ejemplo, Pau, está bloqueando un archivo, el acceso por parte del resto de
desarrolladores no es viable. Si Pau olvida desbloquear el archivo o lo demora durante un tiempo largo,
el resto de compañeros con necesidad de acceder quedarán a la espera para poder continuar su trabajo,
bloqueados por Pau. Esto puede causar muchos problemas de cariz administrativo dentro del equipo de
trabajo.

• A veces, las necesidades de acceso a un mismo archivo son independientes, es decir, se puede requerir
el acceso a diferentes partes del código. Pau puede necesitar editar el inicio de un archivo y Montse
simplemente quiere cambiar la parte final de este archivo. Estos cambios no se superponen en absoluto.
Ellos podrían fácilmente editar el fichero de forma simultánea, y no habría ningún problema siempre que
se asumiera que los cambios se fusionan correctamente. En esta situación no es necesario seguir una
política de bloqueos.

Precisamente, este último problema del sistema de bloqueos es el que sugiere otra solución para el acceso
simultáneo al repositorio.

Fusionar los archivos modificados

Otro sistema para solucionar la problemática de acceso simultáneo a un mismo archivo, como alternativa al
sistema de bloqueo de archivos, es el que se describe a continuación:

• Cada uno de los desarrolladores que necesite editar un archivo se efectuará una copia privada.
• Cada desarrollador editará su copia privada del archivo.
• Finalmente, se fusionarán las diversas copias privadas del archivo modificado.

Esta fusión será automática por parte del sistema, aunque, finalmente, los desarrolladores son los responsables
de dar el visto bueno si la fusión es correcta.

15
Ejemplo: Pau y Montse crean copias de trabajo del mismo proyecto, obtenido del repositorio. Los dos
desarrolladores trabajan simultáneamente efectuando cambios en el mismo fichero A en sus copias locales:

• Montse es la primera a grabar sus cambios al repositorio.

• Cuando Pau intenta guardar sus cambios, el repositorio le informa que su archivo A no está actualizado.
• Pau puede solicitar al asistente que efectúe una propuesta de superposición de los cambios.
• Lo más seguro es que las modificaciones efectuadas por Montse y por Pau no se superpongan, por lo
cual una vez que ambos conjuntos de cambios se han integrado, se graba la nueva versión del archivo en
el repositorio.

Este sistema podrá funcionar de forma sencilla si los cambios de cada uno de los dos desarrolladores no afectan
el trabajo del otro. ¿Pero qué sucede si los cambios del primer desarrollador actúan exactamente en la misma
línea de código fuente que los cambios del segundo? En este caso se podría crear un conflicto. Para evitar este
conflicto, hará falta que el sistema vaya con mucho cuidado a la hora de fusionar los dos archivos. Una posible
forma de actuar seria:

• Cuando Pau pide al asistente que fusione los últimos cambios del repositorio a su copia de trabajo, su
copia del archivo A marca de alguna manera que está en un estado de conflicto.

• Pau será capaz de ver dos conjuntos de cambios conflictivos y, manualmente, podrá elegir entre los dos
o modificar el código porque tenga en cuenta los dos.

• Una vez resueltos los cambios que se superponían de forma manual, podrá guardar de forma segura el
archivo fusionado al repositorio.

Esta situación se tendría que dar pocas veces, puesto que la mayoría de los cambios concurrentes no se
superponen en absoluto y los conflictos no son frecuentes. Además, muchas veces el tiempo que lleva resolver
conflictos es muy menor que el tiempo perdido por un sistema bloqueando.
El sistema de fusión de archivos es el utilizado por algunas herramientas de control de versiones como, por
ejemplo, CVS o Subversion. De esta forma, concluimos que el punto fuerte de este sistema es que permite el

16
trabajo en paralelo de más de un desarrollador o miembro del equipo de trabajo del proyecto, y el punto débil
es que no puede ser utilizado por archivos no fusionables, como podrían ser las imágenes gráficas donde cada
desarrollador modifica la imagen por otra. La buena será o la primera o la segunda, pero no se podrán fusionar.

17