Control Versiones
Short Description
Documento sobre control de versiones...
Description
CONTROL DE VERSIONES (VCS Version Control System) Se llama control de versiones a la gestión de los diversos cambios que se realizan sobre los elementos de algún producto o una configuración del mismo. Una versión, revisión o edición de un producto, es el estado en el que se encuentra el mismo en un momento dado de su desarrollo o modificación. Aunque un sistema de control de versiones puede realizarse de forma manual, es muy aconsejable disponer de herramientas que faciliten esta gestión dando lugar a los llamados sistemas de control de versiones o VCS del ingl!s Version Control System". System". #stos sistemas facilitan la administración de las distintas versiones de cada producto desarrollado, as$ como las posibles especializaciones realizadas por ejemplo, para algún cliente espec$fico". #jemplos de este tipo de herramientas son entre otros% &'S &'S,, Subversion Subversion,, SourceSafe SourceSafe,, &lear&ase &lear&ase,, (arcs (arcs,, )azaar )azaar,, *lastic S&+, S&+, it it,, S&&S S&&S,, +ercurial +ercurial,, *erforce,, -ossil S&+, *erforce S&+ , eam -oundation Server. #l control de versiones se realiza principalmente en la industria inform/tica para controlar las distintas versiones del código fuente dando lugar a los sistemas de control de código fente o S&+ siglas del ingl!s Source Code Management ". ". Sin embargo, los mismos conceptos son aplicables a otros /mbitos como documentos, im/genes, sitios 0eb, etc.
Caracter!sticas Un sistema de control de versiones debe proporcionar%
+ecanismo de almacenamiento de los elementos que deba gestionar ej. archivos de te1to, im/genes, documentación...".
*osibilidad de realizar cambios sobre los elementos almacenados ej. modificaciones parciales, a2adir, borrar, renombrar o mover elementos".
3egistro histórico de las acciones realizadas con cada elemento o conjunto de elementos normalmente pudiendo volver o e1traer un estado anterior del producto".
Aunque no es estrictamente necesario, suele ser muy útil la generación de informes con los cambios introducidos entre dos versiones, informes de estado, marcado con nombre identificativo de la versión de un conjunto de ficheros, etc.
Terminolog!a 4a terminolog$a empleada puede variar de sistema a sistema, pero a continuación se describen algunos t!rminos de uso común. común. 56 3epositorio #l re"ositorio es el lugar en el que se almacenan los datos actualizados e históricos de cambios, a menudo en un ser vidor. A veces se le denomina depósito o depot. *uede ser un sistema de archivos en un disco duro, un banco de datos, etc.. +ódulo &onjunto de directorios y7o archivos dentro del repositorio que pertenecen a un proyecto común. 3evisión "version" "version""" Una revisión es una versión determinada de la información que se gestiona. 8ay sistemas que identifican las revisiones con un contador #j. subversion". 8ay otros sistemas que identifican las revisiones mediante un código de detección de modificaciones #j. it usa S8A5 S8A5"". A la última versión se le suele identificar de forma especial con el nombre de #E$D. *ara marcar una revisión concreta se usan los rótlos o tags. tags. 3otular "tag" "tag""" (arle a alguna versión de cada uno de los ficheros del módulo en desarrollo en un momento preciso un nombre común 9etiqueta9 o 9rótulo9" para asegurarse de reencontrar ese estado de desarrollo posteriormente bajo ese nombre. #n la pr/ctica se rotula a todos los archivos en un momento determinado. *ara eso el módulo se 9congela9 durante el rotulado para imponer una versión coherente. *ero bajo ciertas circunstancias puede ser necesario utilizar versiones de algunos ficheros que no coinciden temporalmente con las de los otros ficheros del módulo. 4os tags permiten identificar de forma f/cil revisiones importantes en el proyecto. *or ejemplo se suelen usar tags para identificar el contenido de las versiones publicadas del proyecto. #n algunos sistemas se considera un tag como una rama en la que los ficheros no evolucionan, est/n congelados. 4$nea base base "baseline" "baseline""" Una revisión aprobada de un documento o fichero fuente, a partir del cual se pueden realizar cambios subsiguientes. Abrir rama "branch" "branch""" o ramificar Un módulo puede ser branched o o %ifrcado en un instante de tiempo de forma que, desde ese momento en adelante se tienen dos copias ramas" que evolucionan de forma independiente siguiendo su propia l$nea de desarrollo. #l módulo tiene entonces 6 o m/s" 9ramas9. 4a ventaja es que se puede hacer un 9merge9 de las modificaciones de ambas ramas, posibilitando la creación de 9ramas de prueba9 que contengan código para evaluación, si se decide que las modificaciones realizadas en la 9rama de prueba9 sean preservadas, se hace un 9merge9 con la rama principal. Son motivos habituales para la creación de ramas la creación de nuevas funcionalidades o la corrección de errores. (esplegar "Check-out" "Check-out",, "checkout", "checkout", 9co9" Un despliegue crea una copia de trabajo local desde el repositorio. Se puede especificar una revisión concreta, y predeterminadamente se suele obtener la última. 9*ublicar9 o 9#nviar9 "commit" "commit",, "check-in", "check-in", 9ci9, "install", "install", "submit"" "submit"" Un commit sucede sucede cuando una copia de los cambios hechos a una copia local es escrita o integrada sobre el repositorio. &onflicto Un conflicto ocurre cuando el sistema no puede manejar adecuadamente cambios realizados por dos o m/s usuarios en un mismo archivo. *or ejemplo, si se da e sta secuencia de circunstancias% 5.
4os 4os us usuari uarios os X X e e Y despliegan despliegan versiones del archivo A en A en que las l$neas n1 hasta n1 hasta n2 son n2 son comunes.
5
6. :. ;.
#l usuario X env$a cambios entre las l$neas n1 y n2 al archivo A. #l usuario Y no actualiza el archivo A tras el env$o del usuario X . #l usuario Y realiza cambios entre las l$neas n1 y n2.
ntegración inversa #l proceso de fundir ramas de diferentes equipos en el trunk principal del sistema de versiones. Actualización "sync" ó "u!date"" Una actali&ación integra los cambios que han sido hechos en el repositorio por ejemplo por otras personas" en la co"ia de tra%a'o local. &opia de trabajo "#orks!ace"" 4a co"ia de tra%a'o es la copia local de los ficheros de un repositorio, en un momento del tiempo o revisión espec$ficos. odo el trabajo realizado sobre los ficheros en un repositorio se realiza inicialmente sobre una copia de trabajo, de ah$ su nombre. &onceptualmente, es un ca'ón de arena o sandbox. &ongelar Significa permitir los últimos cambios commits" para solucionar las fallas a resolver en una entrega release" y suspender cualquier otro cambio antes de una entrega, con el fin de obtener una versión consistente. Si no se congela el repositorio, un desarrollador podr$a comenzar a resolver una falla cuya resolución no est/ prevista y cuya solución d! lugar a efectos colaterales imprevistos.
ormas de cola%orar *ara colaborar en un proyecto usando un sistema de control de versiones lo primero que hay que hacer es crearse una co"ia local obteniendo información del repositorio. A continuación el usuario puede modificar la copia. #1isten dos esquemas b/sicos de funcionamiento para que los usuarios puedan ir aportando sus modificaciones%
(e forma eclsiva% en este esquema para poder realizar un cambio es necesario comunicar al repositorio el elemento que se desea modificar y el sistema se encargar/ de impedir que otro usuario pueda modificar dicho elemento. Una vez hecha la modificación, esta se comparte con el resto de colaboradores. Si se ha terminado de modificar un elemento entonces se libera ese elemento para que otros lo puedan modificar. #ste modo de funcionamiento es el que usa por ejemplo SourceSafe. ?tros sistemas de control de versiones ejemplo% subversion", aunque no obligan a usar este sistema, disponen de mecanismos que permiten implementarlo.
(e forma cola%orativa% en este esquema cada usuario modifica la copia local y cuando el usuario decide compartir los cambios el sistema autom/ticamente intenta combinar las diversas modificaciones. #l 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. Adem/s, esta sem/ntica no es apropiada para ficheros binarios. 4os sistemas de control de versiones subversion o it permiten implementar este modo de funcionamiento.
#l control de versiones eam -oundation Server permite escoger cualquiera de las dos formas de colaboración.
6
$r*itectras de almacenamiento *odemos clasificar los sistemas de control de versiones atendiendo a la arquitectura utilizada para el almacenamiento del código%
Distri%idos% cada usuario tiene su propio repositorio. 4os distintos repositorios pueden intercambiar y mezclar revisiones entre ellos. #s frecuente el uso de un repositorio, que est/ normalmente disponible, que sirve de punto de sincronización de los distintos repositorios locales. #jemplos% it y +ercurial. Centrali&ados% e1iste un repositorio centralizado de todo el código, del cual es responsable un único usuario o conjunto de ellos". Se facilitan las tareas administrativas a cambio de reducir fle1ibilidad, pues todas las decisiones fuertes como crear una nueva rama" necesitan la aprobación del responsable. Algunos ejemplos son &'S, Subversion o eam -oundation Server.
Venta'as de sistemas distri%idos
@ecesita menos veces estar conectado a la red para hacer operaciones. #sto produce una mayor autonom$a y una mayor rapidez.
Aunque se caiga el repositorio remoto la gente puede seguir trabajando
Al hacer los distintos repositorio una r!plica local de la información de los repositorios remotos a los que se conectan, la información est/ muy replicada y por tanto el sistema tiene menos problemas en recuperarse si por ejemplo se quema la m/quina que tiene el repositorio remoto. *or tanto hay menos necesidad de backu!s. Sin embargo, los backu!s siguen siendo necesarios para resolver situaciones en las que cierta información todav$a no haya sido replicada.
*ermite mantener repositorios centrales m/s limpios en el sentido de que un usuario puede decidir que ciertos cambios realizados por !l en el repositorio local, no son relevantes para el resto de usuarios y por tanto no permite que esa información sea accesible de forma pública. *or ejemplo es muy útil se pueden tener versiones inestables o en proceso de codificación o tambi!n tags propios del usuario. #l servidor remoto requiere menos recursos que los que necesitar$a un servidor centralizado ya que gran parte del trabajo lo realizan los repositorios locales.
Al ser los sistemas distribuidos m/s recientes que los sistemas centralizados, y al tener m/s fle1ibilidad por tener un repositorio local y otro7s remotos, estos sistemas han sido dise2ados para hacer f/cil el uso de ramas creación, evolución y fusión" y poder aprovechar al m/1imo su potencial. *or ejemplo se pueden crear ramas en el repositorio remoto para corregir errores o crear funcionalidades nuevas. *ero tambi!n se pueden crear ramas en los repositorio locales para que los usuarios puedan hacer pruebas y dependiendo de los resultados fusionarlos con el desarrollo principal o no. 4as ramas dan una gran fle1ibilidad en la forma de trabajo.
Venta'as de sistemas centrali&ados
#n los sistemas distribuidos hay menos control a la hora de trabajar en equipo ya que no se tiene una versión centralizada de todo lo que se est/ haciendo en el proyecto.
#n los sistemas centralizados las versiones vienen identificadas por un número de versión. Sin embargo en los sistemas de control de versiones distribuidos no hay números de versión, ya que cada repositorio tendr$a sus propios números de revisión dependiendo de los cambios. #n lugar de eso cada versión tiene un identificador al que se le puede asociar una etiqueta tag".
l'os de tra%a'o #l flujo de trabajo de un sistema de control de versiones indica cómo se relacionan los distintos usuarios para colaborar entre s$ en la consecución de los objetivos del proyecto. #n los sistemas de control de versiones centralizados el dise2o del sistema restringe la forma en que los distintos usuarios colaboran entre s$. Sin embargo en los sistemas de control de versiones distribuidos hay mucha m/s fle1ibilidad en la forma de colaborar ya que cada desarrollador puede tanto contribuir como recibir contribuciones. 8ay distintos flujos de trabajo, donde cada uno se adapta mejor a cierto tipo de proyectos. 'eamos algunos ejemplo habituales que tambi!n se pueden combinar para as$ adaptarse mejor al proyecto concreto por ejemplo podr$a usarse en general un flujo centralizado, y usar un gestor de integraciones para ciertas partes cr$ticas y de especial importancia".:
l'o de tra%a'o centrali&ado #n el flujo de trabajo centralizado en ingl!s Centrali$ed %orklo#" cada desarrollador es un nodo de trabajo. *or otro lado hay un repositorio remoto central que funciona a modo de punto de sincronización. odos los nodos de trabajo operan en pie de igualdad sobre el repositorio remoto central. Si se trata de un sistema de control de versiones distribuido cada nodo de trabajo consiste en un repositorio local privado. Una desventaja de este modo de trabajo es que si dos usuarios clonan desde un punto central, y ambos hacen cambios tan solo el primero que env$e sus cambios lo podr/ hacer limpiamente. #l segundo desarrollador deber/ fusionar previamente su trabajo con el del primero, antes de enviarlo, para evitar sobreescribir los cambios del primero. #s decir, es necesario hacer un paso previo ya que no se pueden subir cambios no directos non-astor#ard changes".
l'o de tra%a'o con n +estor de Integraciones #n el flujo de trabajo con un estor de >ntegraciones en ingl!s &ntegration-Manager %orklo#" en el que cada desarrollador tiene acceso de escritura a un repositorio propio público y acceso de lectura a los repositorios públicos de todos los dem/s usuarios. *or otro lado hay un repositorio canónico, representante BoficialB del proyecto.
:
*ara contribuir en estos proyectos cada desarrollador crea su propio clon público del repositorio canónico y env$a sus cambios realizados en un repositorio privado" a !l. *ara BsubirB sus cambios al repositorio canónico cada desarrollador tiene que realizar una petición a la persona gestora del mismo. 4a principal ventaja de esta forma de trabajar es que puedes continuar trabajando, y la persona gestora del repositorio canónico podr/ recuperar tus cambios en cualquier momento. 4as personas colaboradoras no tienen por qu! esperar a que sus cambio sean incorporados al proyecto, cada cual puede trabajar a su propio ritmo.
l'o de tra%a'o con Dictador y Tenientes #l flujo de trabajo con (ictador y enientes en ingl!s 'ictator and (ieutenants %orklo#" es una ampliación del fl'o de tra%a'o con gestor de integraciones. #s utilizado en proyectos muy grandes, con cientos de colaboradores, como el Cernel de 4inu1. 8ay una serie de gestores de integración que se encargan de partes concretas del repositorio, a los que se denominan tenientes. odos los tenientes rinden cuentas a un gestor de integración conocido como el dictador. #l dictador integra todos los aportes de los tenientes publicando el trabajo en un repositorio de referencia del que recuperan todos los colaboradores. #ste sistema de trabajo permite al l$der del grupo el dictador" delegar gran parte del trabajo en los tenientes, relegando su trabajo en recolectar el fruto de múltiples puntos de trabajo.
,so de ramas 4as ramas, en un sistema de control de versiones, constituyen una potente herramienta que fle1ibiliza la forma en la que los colaboradores cooperan en el proyecto en ingl!s )ranching %orklo#s". 4as ramas son solo una herramienta que es posible utilizar de distintas formas para conseguir distintos objetivos. 'eamos algunas posibilidades.:;
Ramas de largo recorrido #n algunos proyectos se tienen varias ramas siempre abiertas, que indican diversos grados de estabilidad del contenido. *or ejemplo, en la rama Dmaster* es frecuente mantener únicamente lo que es totalmente estable. 4uego se tienen otras ramas que revelan distintos grados de estabilidad. *or ejemplo podr$amos tener una rama BbetaB versión beta" y otra BalfaB versión alfa", en las que se va trabajando. &uando se alcanza cierto grado de estabilidad superior a la rama en la que se est/ entonces se realiza una fusión con rama de estabilidad superior.
Ramas "ntales 4as ramas puntuales, tambi!n llamadas ramas de soporte, son ramas que se crean de forma puntual para realizar una funcionalidad muy concreta. *or ejemplo a2adir una nueva caracter$stica se les llama ramas de neva fncionalidad o directamente por su nombre en ingl!s to!ic branch ó eature branch" o corregir un fallo concreto se les llama ramas "ara corregir error o directamente por su nombre en ingl!s hoti branch". #ste tipo de ramas permiten trabajar centr/ndonos e1clusivamente en el desarrollo de una caracter$stica concreta y cuando esta est! concluida se fusiona con una de las ramas de largo recorrido normalmente con la de m/s bajo nivel de estabilidad, para que sea probada en ese entorno". 4a fusión solo se realiza cuando se est/ BseguroB de que esa caracter$stica est/ correctamente implementada, en lugar de fusionar en el orden que se van desarrollando las cosas. #sto permite por un lado tener un historial de las distintas versiones que se han tenido hasta conseguir la funcionalidad. *or otro lado permiten que el historial de las ramas de largo recorrido no sea BensuciadosB con distintas modificaciones relativas a una funcionalidad concreta. #l uso de este tipo de ramas permiten m/s fle1ibilidad a la hora de probar posibles soluciones. Solo se fusiona con ramas de largo recorrido una vez que estamos seguros de elegir la solución mejor. Un tipo de ramas de este tipo que tienen un funcionamiento especial son las llamadas ramas de versión o ramas de release en ingl!s release branch". #ste tipo de ramas se crean para dar soporte a la preparación de una nueva versión de producción. *ermiten tener bajo control el contenido de la versión y poder realizar cierto mantenimiento sobre ella a2adirle peque2as mejoras y corrección de errores". #s frecuente y una buena pr/ctica utilizar en el nombre de la rama un prefijo que indique el tipo de rama de la que se trata. *or ejemplo podr$a usar Deature-* para ramas de nueva funcionalidad, Dhoti-* para ramas que arreglan errores, y Drelease-* para ramas de versión. *3?3A+AS (# &?@3?4 (# '#3S>?@#S 4os "rogramas "ara control de versiones son un grupo de aplicaciones originalmente ideadas para gestionar /gilmente los cambios en el código fuente de los programas y poder revertirlos, cuyo /mbito ha sido ampliado pasando del concepto control de versiones al de gestión de configuración de soft0are, en el que se engloban todas las actividades que pueden realizarse por un equipo sobre un gran proyecto soft0are u otra actividad que genere ficheros digitales por ejemplo% documentos, ofertas, dibujos, esquemas, etc!tera".
-odelo cliente.servidor &on el advenimiento de las redes, los desarrolladores usan un repositorio central al que acceden mediante un cliente en su m/quina. &on el vuelco causado por las redes públicas Usenet, UU&*, >nternet, etc!tera" distinguimos entre programas abiertos código fuente disponible" y propietarios comerciales".
;
Código a%ierto
Concurrent Versions System &'S"% basado originalmente en 3&S, licenciado mediante *4.
&'S@% basado en &'S.
?pen&'S% clon &'S bajo licencia )S(, con !nfasis en seguridad y correcto uso del código fuente.
Subversion svn"% inspirado en &'S.
'esta% sistema de construcción con sopor te para versionado de f icheros en repositorios distribuidos.
/ro"ietario
Accu3ev% herramienta para gestión de la configuración de código fuente que integra un gestor de incidencias basado en flujos que maneja de forma eficiente desarrollo paralelo a escala global tambi!n contempla un servidor para replicación.
&A S&+% herramienta para gestión de cambios y configuración de Com!uter Associates.
AutodesC 'ault% herramienta de control de versiones dise2ada espec$ficamente para aplicaciones Autodesk que gestionan las relaciones complejas entre ficheros de dise2o elaborados por Auto&A( y AutodesC >nventor.
&lear&ase% sistema de gestión de configuración =compaltible con 'SS= fabricado por 3ational Soft0are >)+".
code)eamer% plataforma colaborativa para la gestión del ciclo de vida de aplicaciones.
Coniguration Management Version Control &+'&"% sistema de control de versiones de >)+, retirado.
+lobal 'esign ,latorm (*"% gestión de dise2o de circuitos integrados.
+ES >ntegrity% sistema para gestión del ciclo de vida de aplicaciones soft0are.
*erforce% herramienta con intuitivo interfaz gr/fico, configuración avanzada para funcionamiento en arquitecturas de red complejas = !roy, m/ster=r!plica, broker= y 9funcionamiento o-line9, as$ como interfaz con los >(# m/s e1tendidos y aplicable a documentos no AS&>>.
*'&S% originalmente llamado ,olytron Version Control System, fue desarrollado por (on Einzer para *olytron y lanzado en 5FG
View more...
Comments
