CONTROL DE VERSIONES

ndice
Introduccin Fases de desarrollo del software Caractersticas principales de un SCV Conflictos Sistemas centralizados / distribuidos Esquemas de trabajo con SCV Programas de SCV

Qu es el control de versiones?
Capacidad de recordar todos los cambios que se hacen tanto en la estructura de directorios como en el contenido de los ficheros. Cuando ms de una persona trabaja con los mismos archivos y an cuando es una sola persona resulta imprescindible mantener cierto control sobre los cambios que se realizan: quin, cundo, qu,... . Si los cambios realizados por dos personas son incompatibles y es necesario tomar una decisin sobre la forma definitiva del archivo. Nos damos cuenta que los ltimos cambios realizados no siguen el camino apropiado y debemos volver atrs.

Introduccin
Permite organizar las diferentes versiones de los productos Te permite revertir archivos a un estado anterior o revertir el proyecto entero a un estado anterior, es decir, permite recuperar versiones antiguas y crear una de nuevo a partir de versiones existentes Permite organizar desarrollos especficos de los productos para determinados clientes Comparar cambios a lo largo del tiempo, ver quin modific por ltima vez algo que puede estar causando un problema, quin introdujo un error y cundo, y mucho ms.

Introduccin
Por qu es importante un CSV (Version Control System o VCS en ingls)? Por qu es importante mantener un control de versiones sobre el software que desarrollamos?
Escalabilidad de las aplicaciones Reusabilidad Integridad Productividad

Coordinar varias personas, trabajando en el proyecto en el mismo momento, no es fcily puede ser catico!

Principales funciones de un SCV

Un sistema de control de versiones ha de permitir, al menos tres funciones: Almacenar elementos (ficheros de cdigo, imgenes, documentos, etc.) Realizar cambios a los elementos almacenados, manteniendo la integridad de los datos Mantener un histrico de los cambios realizados, pudiendo volver a estados anteriores si hace falta.

Ciclo de la vida del software

Ciclo secuencial o en cascada

Es un sistema demasiado rgido

Ciclo de la vida del software

Ciclo iterativo incremental

A medida que se va desarrollando el software van surgiendo nuevas necesidades que requieren de nuevas versiones

Ciclo de la vida del software

Ciclo en espiral

Todas las etapas del desarrollo del software se van repitiendo cclicamente hasta a obtener un resultado ptimo del software

Qu es Subversion?
Herramienta de cdigo abierto, multiplataforma (Win32, Linux, Mac, etc), para el control de versiones de ficheros electrnicos, como son el software o la documentacin. Se basa en un repositorio central que acta como un servidor de ficheros, con la capacidad de recordar todos los cambios que se hacen tanto en sus directorios como en sus ficheros. El repositorio incrementa un nmero global de revisin con cada conjunto de cambios enviados (commit) al mismo. Es posible copiar y renombrar ficheros; crear una rama del proyecto es tan fcil como copiar un directorio. Tambin se puede pedir una salida con las diferencias entre dos revisiones arbitrarias, o que recupere algn sub-rbol de la revisin N. http://subversion.tigris.org

Fases de desarrollo
1) Pre Alpha versin preliminar del producto 2) Alpha versin con todos los requerimientos 3) Beta fase de prueba, demo y correccin de errores
Open beta, un grupo grande de gente prueba la versin Closed beta, un grupo reducido y cerrado prueba la versin

4) Candidata (release candidate RC) versin candidata a producto final 5) Versin para fabricacin (release to manufacturing RTM)
versin disponible para ser lanzada al gran pblico

6) Disponibilidad general (general avalability GA) versin disponible al gran pblico

Caractersticas de un CSV
Repositorio, lugar donde se almacenan los datos y ficheros actuales e histricos de todas las versiones. Lnea base (baseline), de todas las versiones realizadas, es la versin aprobada Abrir una rama (branch), iniciar una nueva versin a partir de una versin anterior. Por tanto podemos tener varias versiones desarrollndose en paralelo

Caractersticas de un CSV
Es una copia del proyecto, bajo el control de versiones, pero aislado, de forma que los cambios realizados en esta rama no afecten al resto del proyecto y viceversa, excepto cuando los cambios sean deliberadamente "unidos" de un lado al otro. Las ramas tambin son conocidas como "lneas de desarrollo". Las ramas o branches, permiten aislar diferentes lneas de desarrollo de si mismas. Ejemplo de branching (abrir una nueva rama con una nueva versin que viene de una versin anterior).

Branch y Merge
Al iniciar con control de versiones, uno se pregunta, Cmo ir realizando cambios al cdigo?. Esto es utilizando Branch y Merge. Primero tomamos el trunk y hacemos un branch de este. Despus hacemos las modificaciones sobre el branch y cuando este listo, se fusiona o se hace el Merge con el trunk.

Commit y Update
Podemos hacer posible la colaboracin, haciendo un update de nuestro cdigo, para traer los ltimos cambios y actualizar el cdigo con el que estamos trabajando.

Caractersticas de un CSV
Checkout, obtener una versin en local de alguna versin del repositorio, por tal de trabajarla Merge, mover un cambio de una rama a otra, lo que incluye unir desde la rama principal a otra rama o viceversa. Publicar (commit, check-in), enviar al repositorio una versin probada que hemos estado trabajando en local Bloquear (Locking), un usuario bloquea un fichero para su modificacin sin que el resto lo pueda modificar Congelar, bloquear la posibilidad de nuevos cambios a una versin, por ejemplo un vez se obtiene un producto final que pasa a explotacin.

Conflictos
Cuando diversas personas trabajan sobre la misma versin se pueden producir conflictos. Ejemplo:
1) Dos usuarios (A i B) obtienen (checkout) al mismo fichero. 2) El usuario A cambia el fichero y lo sube al repositorio (commit). 3) El usuario B no actualiza el archivo despus que A haya hecho el commit 4) El usuario B realiza cambios en el mismo punto del fichero que el usuario A. 5) El usuario B intenta posteriormente enviar al repositorio estos cambios al archivo A

En este caso el SCV no es capaz de resolver esta situacin y es necesario la intervencin de algn de los dos usuarios para resolver el problema y obtener la versin correcta del fichero

Conflictos. Modificar los datos bloquendolos

Modelo bloquear-modificar-desbloquear. En esta estrategia, el repositorio permite que solamente un usuario modifique un archivo, para ello primero debe bloquearlo. Cuando otro usuario intente bloquearlo, el sistema no lo permitir y deber esperar a que el primero termine y lo desbloquee Asegura que nadie ms puede modificar los datos. Si dos usuarios acceden al mismo fichero para modificarlo, el primero que lo ha bloqueado no tendr problemas para hacerlo; pero el segundo ya no podr hacer el bloqueo, y SVN le avisar de que el fichero en cuestin ya est bloqueado. El proceso a seguir ser:
Actualizar directorio de trabajo Bloquear datos Modificar datos Validar datos enviando cambios al repositorio, y quitando el bloqueo

Bloquear para evitar conflictos

Bloquear el fichero cuando se est modificando. Es una solucin muy restrictiva
Este modelo ocasiona ciertos problemas: Tiempos muertos: debido a que alguien bloquea un archivo y olvida desbloquearlo, mientras que otro usuario necesita utilizarlo. Esperas injustificadas: en el caso de que un usuario deba modificar una seccin diferente de la que est modificando el usuario bloqueante. Falso sentido de seguridad: en el caso de dependencias entre los archivos, se puede llegar a tener inconsistencias o deadlocks. Estos problemas pueden ser manejados en grupos de desarrollo pequeos y poco distribuidos, donde la comunicacin por vas convencionales es factible.

Conflicto. Modificar los datos sin bloquearlos

Modelo copiar-modificar-combinar. Este modelo permite que mltiples usuarios trabajen simultneamente en sendas copias locales del repositorio (working copy).No bloquea. Mejora la productividad al tener los ficheros siempre accesibles. Si dos usuarios acceden al mismo fichero y lo modifican, el primero que lo actualice no tendr problemas para dejarlo en el repositorio; pero el segundo ya no podr hacerlo, y SVN le avisar de que hay un conflicto y el fichero ha sido modificado, dndole la opcin de revisar las tres versiones (la original, la suya y la del otro) y resolver el conflicto. Si los ficheros en conflicto son de texto, SVN puede ayudarnos a mezclar los cambios. El proceso a seguir ser:
Actualizar directorio de trabajo Modificar datos Validar datos enviando cambios al repositorio

Modificar los datos sin bloquearlos

Fusionar (merge) los dos ficheros en una nueva versin unificada

Sistemas centralizados y distribuidos

Sistemas centralizados: existe un solo repositorio centralizado donde se mantienen todas las versiones. Los cambios solo se hacen sobre el repositorio central. Todos los desarrolladores trabajan con el mismo repositorio Sistemas distribuidos: el enfoque es peer-to-peer, no existe un nico repositorio centralizado, cada usuario tiene su propio repositorio. Cuando un usuario tiene una versin acabada la puede enviar a los repositorios del resto de usuarios

Sistemas centralizados / distribuidos

Ventajas sistemas centralizados:
ms control sobre las versiones. Los administradores tienen control detallado de qu puede hacer cada uno; y es mucho ms fcil administrar un CVCS que tener que lidiar con bases de datos locales en cada cliente. todo el mundo sabe hasta cierto punto en qu est trabajando el resto de gente en el proyecto.

Inconvenientes de los sistemas centralizados:

poca flexibilidad a la hora de hacer merges o bien de crear nuevas ramas de una versin al trabajar contra servidor dependemos de la velocidad de las redes de conexin las copias de seguridad son claves, si se pierde una dada del repositorio central se pierde para siempre. Si el disco duro en el que se encuentra la base de datos central se corrompe, y no se han llevado copias de seguridad adecuadamente, pierdes absolutamente todo toda la historia del proyecto salvo aquellas instantneas que la gente pueda tener en sus mquinas locales si ese servidor se cae durante una hora, entonces durante esa hora nadie puede colaborar o guardar cambios versionados de aquello en que estn trabajando.

Sistemas centralizados / distribuidos

Ventajas sistemas distribuidos:
ms flexibilidad para los programadores (cada programador es libre de crear nuevas versiones, probarlas, etc. Ya que trabaja en local) seguridad. Cada usuario tiene copias de los repositorios

Inconvenientes de los sistemas distribuidos:

mayor curva de aprendizaje (ms encargos) menos control sobre las versiones existentes

Sistema centralizado
Estos sistemas, como CVS, Subversion, y Perforce, tienen un nico servidor que contiene todos los archivos versionados, y varios clientes que descargan los archivos de ese lugar central.

Figura . Diagrama de control de versiones centralizado

Sistema distribuido
Es aqu donde entran los sistemas de control de versiones distribuidos (Distributed Version Control Systems o DVCSs en ingls). En un DVCS (como Git, Mercurial, Bazaar o Darcs), los clientes no slo descargan la ltima instantnea de los archivos: replican completamente el repositorio. As, si un servidor muere, y estos sistemas estaban colaborando a travs de l, cualquiera de los repositorios de los clientes puede copiarse en el servidor para restaurarlo. Cada vez que se descarga una instantnea, en realidad se hace una copia de seguridad completa de todos los datos (vase Figura).
Figura . Diagrama de control de versiones distribuido

Programas de control de versiones

Los ms conocidos son: Sistemas centralizados:
Current Version System (CVS) Subversion, basat en CVS Tortoise, es una plataforma de Subversin para Windows

Sistemas distribuidos:
Git Mercurial Dropbox Bazaar Darcs

CVS vs SVN
CVS y Subversion (tambin conocido como SVN) son los sistemas centralizados de control de versiones libres ms difundidos.

Manejo de subversin
Funciona como un sistema cliente-servidor, donde el servidor admite conexiones de diversos tipos al repositorio. Los clientes pueden utilizar una interfaz de lnea de comandos o un cliente grfico para descargar una working copy para trabajar sobre ella y publicar sus modificaciones.

Glosario de trminos
Branch: El desarrollo puede ramificarse en un momento dado, de forma que dos copias de un archivo puedan ser modificadas independientemente. Check out: Solicitar una working copy desde el repositorio. sta refleja el estado actual del proyecto. Commit/Check in: Enviar los cambios desde la working copy al repositorio. Conflicto: Situacin en la que dos desarrolladores tratan de hacer commit de los cambios realizados a la misma porcin de un archivo. Log message: Comentario describiendo los cambios, que se adjunta a una revisin al momento de hacer commit. Repositorio: Copia maestra del proyecto que almacena la revisin histrica completa. Revisin: Cambio efectuado en la historia de un archivo o conjunto de archivos. Algunos sistemas lo manejan a nivel archivo, otros a nivel proyecto. Update: Traer los cambios realizados por otros usuarios del repositorio a la working copy local. En ese momento se muestran los cambios de la working copy que no han sido confirmados. Working copy: La copia local en la que un usuario realiza modificaciones al proyecto. Tag: Son versiones anteriores que hemos dejado como registro Trunk: Contiene la versin que actualmente estamos utilizando en produccin