REPÚBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA

EDUCACIÓN UNIVERSITARIA
DESARROLLANDO LINKS DE INTERÉS UNIVERSIDAD ALEJANDRO DE HUMBOLDT

SOFTWARE Para documentación:

El desarrollo de so
ware no es una CVS : hAp://www.nongnu.org/cvs/
tarea exclusivamente individual. En la gran Subversion : hAp://subversion.%gris.org/
mayoría de los proyectos tanto Open Source
Mercurial : hAp://mercurial.selenic.com/wiki/
como privados, es necesario trabajar en
Git : hAp://git-scm.com/documenta%on
equipos en donde son varios los desarrolla-
dores que acceden al mismo código fuente.

Coordinar las modificaciones concu-

CONTROL DE
rrentes al código de una forma manual Para descargas:
puede ser una tarea extremadamente di$cil,
sobre todo en proyectos muy complejos o
con una gran can%dad de desarrolladores.
CVS : hAp://
p.gnu.org/non-gnu/cvs/ VERSIONES
Subversion : hAp://www.visualsvn.com/server/
Los sistemas de control de versiones Mercurial : hAp://mercurial.selenic.com/downloads/
son potentes herramientas que permiten Git : hAp://git-scm.com/download
ges%onar de forma automá%ca los diversos
cambios que se realizan sobre el so
ware
que se esté desarrollando. Existe gran can%-
dad de sistemas de control de versiones en
el mercado, tanto en So
ware Libre como
con licencia. De estos sistemas se podrían
mencionar el CVS, Subversion, Mercurial,
Git, entre otros.

Ingeniería del So
ware Expositor:

Sección 501 Rojas, Miguelangel

Caracas, abril 2011

 CONCEPTOS BÁSICOS
Versión: Es el estado en el que se encuentra un producto de
-
so
ware en un momento dado de su desarrollo o modifica-
ción. También se le llama revisión.
Control de Versiones: Es la ges%ón de los diversos cambios
que se realizan sobre los elementos de algún producto de
so
ware o una configuración del mismo.
Configuración: Es una combinación de versiones par%culares
de los componentes que forman un so
ware consistente.
Cambio: Es el paso de una versión de la línea base a la si-
guiente. Puede incluir modificaciones del contenido de algún
componente, y/o modificaciones de la estructura del siste-
ma, añadiendo o eliminando componentes.
Línea Base: Es una configuración opera%va del so
ware, a
par%r del cual se pueden realizar cambios.
Módulo: Conjunto de directorios y/o archivos dentro del
repositorio, que pertenecen a un proyecto común.
ware desarrollado. el conflicto, para que sea resuelto manualmente. Si el commit es
Tag: Es una e%queta para una colección par%cular de ficheros
en una revisión específica. Los tags son u%lizados para pre-
servar capturas importantes del proyecto.
Tronco: Es la variante principal en el desarrollo de un so
wa- la copia local existen dos semán%cas básicas:
re.
ware libre y
Rama: Son las variantes secundarias en el desarrollo de un
so
ware. Es una copia del proyecto, bajo el control de versio-
nes, pero aislado, de forma que los cambios realizados en
esta rama no afecten al resto del proyecto y vice versa. Tam-
bién se les conoce como "línea de Desarrollo".
Variante: Es una versión de un componente (o de la configu-
ración global) que evoluciona por separado.
Fusión de variantes: Una integración o fusión une dos con-
juntos de cambios sobre un fichero o un conjunto de ficheros
en una revisión unificada de dicho fichero o ficheros.
Repositorio: es el lugar en el que se almacenan los datos
actualizados e históricos, a menudo en un servidor. A veces
se le denomina depósito o depot. Puede ser un sistema de
archivos en un disco duro, una base de datos, etc.
Desplegar (Checkout): Consiste en crear una copia de trabajo
local desde el repositorio.
Publicar (Commit, check-in, submit): Consiste en integrar los
cambios realizados a una copia local del proyecto, en el
repositorio.
Actualización (Sync, update): Consiste en actualizar la copia
local del trabajo, con los cambios realizados en el repositorio
después que se realizó el checkout.
Conflicto: Sucede cuando dos o más personas intentan reali-
zar diferentes cambios en la misma porción de código.
SISTEMAS DE CONTROL DE VERSIONES
Aunque es posible controlar las versiones de un producto de so
ware de forma manual, es mas eficaz hacerlo u%lizando herramientas
diseñadas para tal fin, sobre todo en proyectos complejos o que ameri-
ten múl%ples desarrolladores. Estas herramientas %enen como obje%-
vos principales, brindar un ambiente propicio que permita mezclar
dis%ntos cambios al código para consolidar un código único final de
una forma automa%zada, siempre que sea posible. Así como mantener
un registro de los cambios que se realicen al código fuente de tal ma-
nera que se tenga acceso a todo el historial de cambios del proyecto y
se puedan rever%r cambios en caso de ser necesario.
FUNCIONAMIENTO
Todos los sistemas de control de versiones poseen un repositorio
el cual con%ene el historial de versiones del so
Cada uno de los usuarios puede crearse una copia local duplicando
el contenido del repositorio para permi%r su uso. Es posible duplicar la
úl%ma versión o cualquier versión almacenada en el historial. Este
proceso se suele conocer como checkout o desproteger. Para modificar
Exclusivos: para poder realizar un cambio es necesario marcar en el
repositorio el elemento que se desea modificar y el sistema se encarga-
rá de impedir que otro usuario pueda modificar dicho elemento.
Colaboravos: En el que cada usuario se descarga la copia, la modifica,
y el sistema automá%camente combina las diversas modificaciones. El
principal problema es la posible aparición de conflictos que deban ser
solucionados manualmente o las posibles inconsistencias que surjan al
modificar el mismo fichero por varias personas no coordinadas. Ade-
más, esta semán%ca no es apropiada para ficheros binarios.
Tras realizar la modificación es necesario actualizar el repositorio
con los cambios realizados. Habitualmente este proceso se denomina
publicar, commit, check in o proteger.
CLASIFICACIÓN
Centralizados: Existe un repositorio centralizado de todo el códi-
go, del cual es responsable un único usuario (o conjunto de ellos). Se
facilitan las tareas administra%vas a cambio de reducir flexibilidad,
pues todas las decisiones fuertes (como crear una nueva rama) necesi-
tan la aprobación del responsable. Ejemplos: CVS y Subversion
Distribuidos: Cada usuario %ene su propio repositorio. No es
necesario tomar decisiones centralizadamente. Los dis%ntos reposito-
rios pueden intercambiar y mezclar revisiones entre ellos. Ejemplos:
Git y Mercurial.
SISTEMAS DE CONTROL DE VERSIONES
MAS POPULARES
CVS: El Concurrent Versions System (CVS) es un sistema de
control de versiones que u%liza una arquitectura cliente-servidor: un
servidor guarda la(s) versión(es) actual(es) del proyecto y su historial.
Los clientes se conectan al servidor para sacar una copia completa
del proyecto. Esto se hace para que eventualmente puedan trabajar
con esa copia y más tarde ingresar sus cambios con comandos GNU.
Generalmente cliente y servidor se conectan u%lizando Internet, pero
con el sistema CVS el cliente y servidor pueden estar en la misma
máquina. El sistema CVS %ene la tarea de mantener el registro de la
historia de las versiones del programa de un proyecto solamente con
desarrolladores locales.
En el CVS, varios clientes pueden sacar copias del proyecto al
mismo %empo. Posteriormente, al hacer commit, el servidor trata de
acoplar las diferentes versiones. Si se presenta algún conflicto, el
servidor deniega la segunda actualización e informa al cliente sobre
exitoso, los números de versión de todos los archivos implicados se
incrementan automá%camente y el servidor CVS almacena informa-
ción sobre la actualización, que incluye una descripción suministrada
por el usuario, la fecha y el nombre del autor y sus archivos log.
Subversion es un sistema de control de versiones diseñado
específicamente para reemplazar al popular CVS. Es so
se le conoce también como svn por ser el nombre de la herramienta
u%lizada en la línea de órdenes. Una caracterís%ca importante de
Subversion es que, a diferencia de CVS, los archivos versionados no
%enen cada uno un número de revisión independiente, en cambio,
todo el repositorio %ene un único número de versión que iden%fica
un estado común de todos los archivos del repositorio en un instante
determinado.
Mercurial: Está implementado principalmente haciendo uso del
lenguaje de programación Python, pero incluye una implementación
binaria de diff escrita en C. Mercurial fue escrito originalmente para
funcionar sobre Linux. Ha sido adaptado para Windows, Mac OS X y
la mayoría de otros sistemas %po Unix. Las principales metas de
desarrollo de Mercurial incluyen un gran rendimiento y escalabilidad;
desarrollo completamente distribuido, sin necesidad de un servidor;
ges%ón robusta de archivos tanto de texto como binarios; y capacida-
des avanzadas de ramificación e integración, todo ello manteniendo
sencillez conceptual. Incluye una interfaz web integrada. Al igual que
git y Monotone, Mercurial usa resumenes SHA-1 para iden%ficar
revisiones. Para el acceso a repositorios mediante red, Mercurial usa
un protocolo eficiente, basado en HTTP, que persigue reducir el
tamaño de los datos a transferir, así como la proliferación de pe%cio-
nes y conexiones nuevas. Mercurial puede funcionar también sobre
ssh, siendo el protocolo muy similar al basado en HTTP.