Universidad Mundo Maya

SISTEMAS DE CONTROL DE VERSIONES

Francisco Javier Herrera Rivas
e-mail: Fco.Herrera.1907@gmail.com
Gestin de Proyectos de Software
Ing. En sistemas computacionales 8vo Semestre
Dr. Edgar Martin Lorca Velueta

que ser introducido segn el tpico a lo largo de este libro.

Ahora, vamos a concentrarnos en seleccionar y configurar un
sistema de control de versiones de forma que fomentemos un
desarrollo cooperativo.
Un sistema de control de versiones es una herramienta que
registra todos los cambios hechos en uno o ms proyectos,
guardando as versiones del producto en todas sus fases del
desarrollo. Las versiones son como fotografas que registran su
estado en ese momento del tiempo y se van guardando a
medida que se hacen modificaciones al cdigo fuente.
Antes de la masificacin de los sistemas de control de
versiones, se solan guardar los hitos (una especie de versin)
del proyecto en archivos comprimidos y medios de
almacenamiento como diskettes y CDs. Los sistemas de
control de versiones nacen de la necesidad de solventar y
facilitar este tedioso proceso.
Para un desarrollador esta herramienta es muy
valiosa porque permite viajar atrs en el tiempo (hacer
rollback) si los cambios aplicados no resultaron de la manera
que se esperaba, pudiendo restaurar en cualquier momento una
versin previa. Es como un respaldo permanente. Hoy en da
son usados no solo por desarrolladores independientes sino
tambin por startups y grandes corporaciones. Es que tener la
posibilidad de volver atrs no tiene precio.
Algunos de los sistemas de control de versiones ms
famosos
son Subversin
(tambin
conocido
como
Svn), Git y Mercurial.
2.1 Qu es un sistema de control de versiones y qu se
puede hacer con l
En un entorno donde existe diversos desarrolladores de
cdigo fuente, el control de la concurrencia, as como disponer
del histrico de modificaciones realizadas sobre los distintos
archivos es muy importante. Con un sistema de control de
versiones puedes revertir la situacin de ciertos ficheros
(incluso el proyecto completo) a estados anteriores, realizar
comparativas entre las distintas versiones, localizar desde
cuando se est produciendo un error, determinar el responsable
del error, disponer de copias de seguridad de esos mismos
archivos, etc.
Dos
arquitecturas
tpicas
son
las distribuidas y
las centralizadas. Los distribuidos son ms habituales en
grandes proyectos donde los desarrolladores se encuentran en
mltiples localizaciones, se da la necesidad de replicar los
repositorios y donde se producen mltiples ramas que
terminarn (o no) fusionndose con la rama principal. Las
centralizadas, por el contrario, son ms habituales en pequeas
empresas y/o proyectos donde existe una mayor necesidad de
trabajo en equipo.
Desde mi punto de vista, y pensando en la apuesta por el
desarrollo de ERP sectorizado y vertical, el modelo de control
de versiones centralizado me parece ms eficaz, si bien con un
servidor replicado que pueda entrar en uso inmediatamente tras
una cada generalizada del sistema. Puesto que existe un

RESUMEN: La razn por la cual el control de

versiones es universal es porque ayuda virtualmente en todos
los aspectos al dirigir un proyecto: comunicacin entre los
desarrolladores, manejo de los lanzamientos, administracin
de fallos, estabilidad entre el cdigo y los esfuerzos de
desarrollo experimental y atribucin y autorizacin en los
cambios de los desarrolladores.
PALABRAS CLAVE: sistemas, control de software.

1.- INTRODUCCIN
Gracias a todas las herramientas que la tecnologa nos
provee, cada da el desarrollo de software se vuelve ms
eficiente. Existe una gran variedad de ellas, pero hay una que
se destaca entre todas y que le da al desarrollador la capacidad
de gestionar de una manera sencilla y oportuna sus proyectos:
un sistema de control de versiones.

2.- DESARROLLO.
2. SISTEMAS DE CONTROL DE VERSIONES

Un sistema de control de versiones (o sistema de control de

revisiones) es una combinacin de tecnologas y prcticas para
seguir y controlar los cambios realizados en los ficheros del
proyecto, en particular en el cdigo fuente, en la
documentacin y en las pginas web. Si nunca antes se ha
utilizado un control de versiones, lo primero que hay que hacer
es conseguir a alguien que s lo haya hecho y hacer que se una
al proyecto. Hoy en da todo el mundo espera que al menos el
cdigo fuente del proyecto est bajo un control de versiones y
probablemente no se tomen el proyecto seriamente si no se
utiliza este sistema con un mnimo de competencia.
La razn por la cual el control de versiones es universal es
porque ayuda virtualmente en todos los aspectos al dirigir un
proyecto: comunicacin entre los desarrolladores, manejo de
los lanzamientos, administracin de fallos, estabilidad entre el
cdigo y los esfuerzos de desarrollo experimental y atribucin
y autorizacin en los cambios de los desarrolladores. El
sistema de control de versiones permite a una fuerza
coordinadora central abarcar todas estas reas. El ncleo del
sistema es la gestin de cambios: identificar cada cambio a los
ficheros del proyecto, anotar cada cambio con meta-data como
la fecha y el autor de la modificacin y disponer esta
informacin para quien sea y como sea. Es un mecanismo de
comunicacin donde el cambio es la unidad bsica de
informacin.
An no hemos discutido todos los aspectos de utilizar un
sistema de control de versiones ya que es un tema tan extenso

Universidad Mundo Maya

[1] G. Obregn-Pulido, B. Castillo-Toledo and A. Loukianov, A

globally convergent estimator for n frequencies, IEEE Trans. On
Aut. Control. Vol. 47. No 5. pp 857-863. May 2002.
[2] H. Khalil, Nonlinear Systems, 2nd. ed., Prentice Hall, NJ, pp.
50-56, 1996.
[3] Francis. B. A. and W. M. Wonham, The internal model principle
of control theory, Automatica. Vol. 12. pp. 457-465. 1976.
[4] E. H. Miller, A note on reflector arrays, IEEE Trans. Antennas
Propagat., Aceptado para su publicacin.
[5] Control Toolbox (6.0), Users Guide, The Math Works, 2001, pp.
2-10-2-35.
[6] J. Jones. (2007, Febrero 6). Networks (2nd ed.) [En lnea].
Disponible en: http://www.atm.com.

equipo de trabajo concentrado en una misma ubicacin fsica,

no es un problema una cada de internet, el nmero de ramas
puede ser controlado, el versionado es comn, y el
mantenimiento se puede realizar de forma centralizada.
2.2 Comparacin entre Subversin y CVS
CVS y Subversion (SVN)
sirven
para controlar
las
versiones y la historia de los proyectos software. Por lo tanto, a
grandes rasgos, permiten:
que varias personas puedan trabajar en un mismo
proyecto sin afectarse mutuamente en el trabajo que
realiza,
que haya un histrico de revisiones, por seguridad y
para poder recuperar una versin anterior de nuestro
cdigo,
gestionar versiones de la aplicacin, derivaciones y
dems.
Podramos decir que las instancias de CVS y Subversion
son repositorios, es decir, un almacn de ficheros, sus
versiones y su historial de cambios.
CVS:
Licencia gratuita, Multiplataforma.
Orientado a ficheros: Versiona los ficheros, no el proyecto.
Esto quiere decir que cada modificacin en cada fichero hace
variar la versin del fichero modificado.
Enva ficheros completos: Cuando se hace una
modificacin en un fichero, se sube al repositorio el fichero
entero, en vez de slo los cambios.
Soporte Unicode limitado: Puede traer problemas con
caracteres "raros".
Renombrar/eliminar: No da soporte. Hay que hacerlo
manualmente: copiar con otro nombre y borrar el antiguo.
Subversin (SVS):
Licencia gratuita, Multiplataforma.
Orientado a proyectos: Versiona los proyectos, no los
ficheros. Es una opcin mucho ms intuitiva que no la de
versionar ficheros.
Enva slo cambios: Cuando se hace una modificacin en
un fichero, se sube al repositorio el cambio realizado, no el
fichero entero. Ms eficiencia.
Soporte Unicode: En principio no debera dar problemas de
esta ndole.
Renombrar/eliminar: Da soporte parcial. El usuario lo hace
en una nica operacin pero SVN internamente lo hace las dos
cosas en una transaccin de forma transparente al usuario:
copiar con otro nombre y borrar el antiguo.

Observaciones:
1. El trabajo debe contener como mximo 4
cuartillas y como mnimo 3.
2. Ms de 4 errores ortogrficos y gramaticales
anulan el trabajo.
3. Trabajos con hipervnculo se anulan
4. Trabajos iguales se anulan.
5. Trabajos individuales.

2.3 Subversin con eclipse

CONCLUSIONES
REFERENCIAS