Metodologia para trabajar en SVN

PROTOCOLO PARA TRABAJAR CON REPOSITORIOS SVN POR
MEDIO DE RAMAS
Autores:
MARIA CONSUELO FRANKY
JOHN EDDIE DÍAZ AGUDELO
JUAN FELIPE OLAYA
PONTIFICIA UNIVERSIDAD JAVERIANA
DEPARTAMENTO DE INGENIERÍA DE SISTEMAS
CARRERA DE INGENIERÍA DE SISTEMAS
BOGOTÁ D.C.
2010.
Tabla de Contenido
1
PRELIMINARES ..................................................................................................................................................... 3
1.1
1.2
1.3
2
INSTALACIÓN Y ADMINISTRACION DE SUBVERSION ............................................................................. 4
2.1
2.2
2.3
2.4
3
DISCIPLINA DE TRABAJAR EL TRONCO O LA RAMA COMO UN TODO.................................................................... 7
REGISTRAR BUENOS COMENTARIOS CON LOS COMANDOS SUBVERSION ............................................................. 7
MINIMIZAR LOS CONFLICTOS EN LA INTEGRACIÓN DE LAS RAMAS AL TRONCO .................................................. 7
PROTOCOLO DE TAREAS .................................................................................................................................. 9
4.1
4.2
4.3
4.4
5
INSTALACIÓN DE SUBVERSION........................................................................................................................... 4
CREACIÓN DE UN REPOSITORIO SUBVERSION..................................................................................................... 4
ADMINISTRACIÓN DE USUARIOS, PERMISOS Y BACKUPS DE UN REPOSITORIO SUBVERSION ................................ 5
INSTALACIÓN DEL PLUGIN SUBVERSION PARA ECLIPSE ...................................................................................... 6
RECOMENDACIONES IMPORTANTES ............................................................................................................ 7
3.1
3.2
3.3
4
ENTRADAS ......................................................................................................................................................... 3
CRITERIOS DE EJECUCIÓN .................................................................................................................................. 3
TÉRMINOS USADOS ............................................................................................................................................ 3
TAREAS DEL ADMINISTRADOR PARA CREAR UNA NUEVA RAMA......................................................................... 9
TAREAS DEL DESARROLLADOR PARA TRABAJAR EL REQUERIMIENTO EN LA RAMA.......................................... 12
TAREAS DEL RESPONSABLE DE HACER PRUEBAS SOBRE UNA RAMA ................................................................. 15
TAREAS DEL ADMINISTRADOR PARA INTEGRAR LA RAMA AL TRONCO ............................................................. 16
LIBERACIÓN DE CAMBIOS .............................................................................................................................. 19
5.1
5.2
5.3
5.4
VERIFICACIÓN ................................................................................................................................................. 19
METRICS .......................................................................................................................................................... 19
CRITERIO DE FINALIZACIÓN ............................................................................................................................. 19
SALIDAS .......................................................................................................................................................... 19
pg. 2
1 PRELIMINARES
1.1 ENTRADAS


Requerimiento de hacer una modificación o una extensión a un repositorio Subversion.
Nombre del desarrollador (o desarrolladores) que tiene a cargo el requerimiento.
1.2 CRITERIOS DE EJECUCIÓN



Orden de realizar el requerimiento por parte de los arquitectos.
Los desarrolladores deben estar registrados como usuarios ante el repositorio.
Teniendo en cuenta que la raíz del repositorio corresponde al directorio tiggerRummy, los
desarrolladores deben hacer checkout del proyecto correspondiente al subdirectorio
tiggerRummy/technical (en lo sigue se asume que éste es el tronco y proyecto de referencia; un
proyecto diferente tendrá otro subdirectorio como su tronco).
1.3 TÉRMINOS USADOS

Versión: Estado de un conjunto de clases (y de otro tipo de archivos) que forman un sistema o
componente. El conjunto de clases forman una versión en un momento dado.

Versión en producción: Es una versión de un sistema o componente que se encuentra disponible para
el uso de usuarios finales.

Versión en desarrollo: Versión de un sistema o componente que está sufriendo modificaciones por
mejoras o correcciones, aún no está disponible para producción.

Tronco: Es un término equivalente a la versión estable oficial de desarrollo.

Rama (Branch): Versión de desarrollo paralela a la versión oficial (tronco) que se trabaja hasta tenerla
lista para salir a pruebas y posterior producción. Ambas versiones, la oficial y la rama comparten un
ancestro común y están destinadas a converger en el futuro cercano. Para múltiples desarrollos
paralelos se debe crear una rama para cada uno de ellos y luego integrarlos secuencialmente al tronco.

Etiqueta (Tag): Copia de la versión oficial tomada en cierto momento. A diferencia de las ramas, las
versiones con etiquetas no deberían sufrir modificaciones.

Directorios del tronco, de ramas y de etiquetas: para el repositorio tiggerRummy se tienen los
siguientes directorios:
o tiggerRummy/technical: Directorio del tronco
o tiggerRummy/branches: Directorio de ramas
o tiggerRummy/tags: Directorio de etiquetas
pg. 3
2 INSTALACIÓN Y ADMINISTRACION DE SUBVERSION
2.1 INSTALACIÓN DE SUBVERSION
Generalmente Subversion ya viene instalado en varios sistemas Linux, por ejemplo CentOS 5.x y
superior.
Los ambientes de desarrollo colaborativos SourceForge y GForge también instalan Subversion (y
CVS).
2.2 CREACIÓN DE UN REPOSITORIO SUBVERSION
Suponiendo que el directorio raíz de instalación de Subversion es: /datos/svn.repository/
la creación del repositorio tiggerRummy (para el proyecto TiggerRummy) se realiza mediante el
comando create de Subversion, de la siguiente manera:
cd /datos/svn.repository/
svnadmin create tiggerRummy
Para que el repositorio tiggerRummy pueda accederse por la web, debe configurarse Apache
editando el archivo: /etc/httpd/conf.d/subversion.conf, añadiendo la siguiente
sección (en donde se indica los nombres del archivo de permisos y de passwords):
<Location /tiggerRummy>
DAV svn
SVNPath /datos/svn.repository/tiggerRummy
#
# Limit write permission to list of valid users.
# <LimitExcept GET PROPFIND OPTIONS REPORT>
# Require SSL connection for password protection.
# SSLRequireSSL
AuthType Basic
AuthName "Repository"
AuthUserFile
/datos/svn.repository/tiggerRummy.htpasswd
AuthzSVNAccessFile
/datos/svn.repository/tiggerRummy.permission
Require valid-user
# </LimitExcept>
</Location>
pg. 4
2.3 ADMINISTRACIÓN
DE USUARIOS, PERMISOS Y BACKUPS DE UN REPOSITORIO
SUBVERSION
La persona encargada de las labores administrativas del repositorio, puede remitirse al manual de
Subversion: “version control with subversión.pdf” localizado en la siguiente ubicación dentro del
CD de ConstruColectiva:
/Guia/Anexos/version control with subversión.pdf
Es importante restringir en los permisos que solo usuarios con el rol de administrador puedan
modificar el tronco del repositorio (para creación e integración de nuevas ramas al tronco).
Los comandos más frecuentes se ilustran a continuación:

Definición de permisos para el repositorio tiggerRummy: editar el archivo
/datos/svn.repository/tiggerRummy.permission siguiendo las instrucciones
del manual.

Crear el archivo tiggerRummy.htpasswd de passwords con el password de un primer
usuario:
htpasswd -cm tiggerRummy.htpasswd jperez

Para agregar el password de otro usuario o cambiar un password existente:
htpasswd -mb tiggerRummy.htpasswd jperez elpassword

Para eliminar un usuario:
htpasswd -D tiggerRummy.htpasswd jperez

Producir un backup mediante dump (exportación):
cd /datos/svn.repository/
svnadmin dump /datos/svn.repository/tiggerRummy > tiggerRummy2009-12-30.dmp
Este backup puede importarse a un repositorio vacío (en la misma máquina o en otra
máquina):
svnadmin create newtiggerRummy
svnadmin load newtiggerRummy < tiggerRummy-2008-03-30.dmp
pg. 5
2.4 INSTALACIÓN DEL PLUGIN SUBVERSION PARA ECLIPSE
Como cliente para interactuar con Subversion se puede utilizar el programa TortoiseSVN (cliente
web; ver http://tortoisesvn.tigris.org/) o el plugin para Eclipse: Subclipse. En este documento se
darán instrucciones suponiendo que los desarrolladores tienen instalado el plugin para Eclipse.
Para instalar el plugin de Subversion para Eclipse se deben seguir las instrucciones que se
encuentran en la página web: http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA
A continuación se resumen los puntos importantes de esta instalación:
1- En Eclipse entrar por updates >> find and install >> search for new features
2- Definir New remote site:
Name: Subclipse
corresponde a: 1.2.x (Eclipse 3.2+)
URL: http://subclipse.tigris.org/update_1.2.x
3- Instalar y reiniciar Eclipse
4- Abrir perspectiva: SVN
(Podrían integrarse las ventanas de esta perspectiva a la perspectiva Team)
5- Definir acceso a repositorio Subversion:
Indicar URL, usuario/password
Ejemplo: http://197.0.2.24/tiggerRummy
http://197.0.2.24/tiggerRummy/processes
6- Sobre el repositorio definido hacer checkout creando nuevo proyecto en Eclipse.
pg. 6
3 RECOMENDACIONES IMPORTANTES
3.1 DISCIPLINA DE TRABAJAR EL TRONCO O LA RAMA COMO UN TODO
Para evitar inconsistencias tanto en el tronco como en cualquiera de las ramas que se creen es
necesario realizar los comandos de Subversion a nivel de todo el tronco o de toda la rama que se esté
trabajando:





El checkout inicial del proyecto debe tomar todo el tronco.
Toda rama o etiqueta representa una copia de todo el tronco. La copia correspondiente a una etiqueta
no se modifica para que corresponda a una versión congelada del tronco.
Para cambios hechos en una rama debe hacerse un commit de toda la rama y no de archivos
individuales.
Los comandos de integración deben llevar los cambios ocurridos en todo el tronco hacia una rama o
integrar toda una rama hacia el tronco. Después de estas integraciones debe hacerse un commit de toda
la rama o de todo el tronco, según el caso.
Las etiquetas representan versiones del tronco antes de la creación de una rama; también antes y
después de la integración de la rama al tronco.
3.2 REGISTRAR BUENOS COMENTARIOS CON LOS COMANDOS SUBVERSION
Los comandos Subversion requieren un comentario. Para los comandos de creación de ramas,
etiquetas e integraciones se recomienda configurar o seleccionar los templates de comentarios que
ya están configurados, como son los siguientes:







TAG of trunk before creating branch.XX
BRANCH branch.XX creation for <purpose>
TAG of trunk before integrating branch.XX
TAG of trunk after integrating branch.XX
INTEGRATION: confirming integration of branch.XX to the trunk
INTEGRATION: confirming integration of trunk to the branch.XX
NEW INSTALLER: version XXX
Durante el desarrollo de una rama se recomienda hacer commits frecuentes para hacer visibles los
cambios a los otros desarrolladores de la rama. El comentario de un commit debe indicar la
naturaleza de cada cambio que se está registrando (ej: fixing problem of XXX template with MySQL
database for inserting BLOB data) en lugar de un comentario genérico que no da información (ej:
“fixing problem”).
3.3 MINIMIZAR LOS CONFLICTOS EN LA INTEGRACIÓN DE LAS RAMAS AL TRONCO
Después de cada integración de una rama al tronco, el administrador debe avisar para que todos los
desarrolladores actualicen sus ramas activas integrando el tronco hacia cada rama. De esta manera
las ramas se mantienen actualizadas respecto al tronco y se reduce la probabilidad de que ocurran
conflictos en la integración de una próxima rama al tronco.
pg. 7
Para cada integración de una rama al tronco debe obtenerse el log de integración y agregarle como
se resolvieron los conflictos, si los hubo. El administrador envía este log al responsable de la rama
integrada para que confirme si fue correcta la resolución de conflictos.
Otra práctica adicional para minimizar conflictos es que el administrador no integre varias ramas al
tronco en forma consecutiva sino que permita después de cada integración que los desarrolladores
actualicen sus ramas activas, antes de proceder a una siguiente integración de otra rama al tronco.
En general no deberían hacerse cambios sobre una rama que ya ha sido integrada al tronco.
pg. 8
4 PROTOCOLO DE TAREAS
4.1 TAREAS DEL ADMINISTRADOR PARA CREAR UNA NUEVA RAMA
El desarrollador (o grupo de desarrolladores) que tiene a cargo el requerimiento de hacer una
modificación o extensión al proyecto TiggerRummy, debe solicitar al Administrador del repositorio
la creación de una rama a partir del tronco (por política de permisos solo usuarios con rol
administrador en el repositorio pueden crear ramas).
TAREA
RESPONSABLE
ACLARACIONES
Comandos desde el cliente de
Subversion en Eclipse
1- TOMAR EL TRONCO
ACTUALIZADO:
Si es la primera vez que se
toma el proyecto
correspondiente al tronco:


Conectarse al
repositorio:
http://197.0.2.24/tigger
Rummy /technical
(cambiar el IP a
190.25.225.157 por
fuera de la red local)
Aplicar al repositorio asociado al tronco
el comando Checkout
Administrador del
repositorio
No debería haber
cambios pendientes
sobre el tronco,
suponiendo que todo
cambio se maneja en una
rama.
Hacer un checkout de
este repositorio
Aplicar al proyecto el comando Team >
Update
Si ya se tiene el proyecto
correspondiente al tronco:

Hacer un update del
proyecto
2MARCAR LA VERSION
ACTUAL DEL TRONCO
CON UNA ETIQUETA
Administrador del
repositorio
Con la etiqueta se logra
tener una versión de
referencia de cómo
estaba el tronco antes de
la extensión o
modificación.
Para crear una etiqueta
se necesita rol de
administrador.
Averiguar cuál es la revisión actual del
repositorio mediante el comando: Show
History, usado en la vista SVN
Repository (notar que es la revisión del
repositorio
tiggerRummy/
y
no
únicamente
del
tronco
tiggerRummy/technical/ pues se quiere
tener en cuenta todas las revisiones del
tronco, de las ramas y de las etiquetas).
Aplicar al proyecto el comando Team >
Branch/Tag :
En el FROM indicar el URL del tronco:
http://197.0.2.24/tiggerRummy /technical
En el TO indicar el URL de la nueva
etiqueta, por ejemplo:
pg. 9
http://197.0.2.24/tiggerRummy/tags/5.81.00
Observar que existe un subdirectorio tags
(al mismo nivel del tronco) destinado a
reunir las versiones etiquetadas del
tronco.
Cada etiqueta
compuesto de :
recibe
un
nombre
[version].[revision].[bugs arreglados]
Donde :
[version] Es la versión mayor del
framework, actualmente 5
[revision] Es la revisión actual del tronco
[bugs arreglados] Es el número de bugs
arreglados en la versión del tronco
asociada a esta etiqueta; solo será
diferente de 00 cuando se marque una
etiqueta al integrar al tronco una rama en
la que se arregló algún problema.
En el ejemplo 5.81.00 nos referimos a la
versión mayor 5, revision 81 con 0 bugs
arreglados.
Dejar seleccionado HEAD revision para
que la etiqueta tome el estado actual del
tronco.
El comentario asociado a la etiqueta debe
comenzar por la palabra TAG e indicar
que es la versión antes de crear la rama
en donde se hará el cambio (por ejemplo:
“TAG of trunk before creating
branch.DB2”).
Aplicar al proyecto el comando Team >
Branch/Tag
En el FROM indicar el URL del tronco:
http://197.0.2.24/tiggerRummy /technical
3- ABRIR UNA RAMA A
PARTIR DEL TRONCO:
Administrador del
repositorio
Sólo un usuario
administrador crea la
rama.
En el TO indicar el URL de la nueva
rama, por ejemplo:
http://197.0.2.24/tiggerRummy/branches
/branch.DB2
Observar que existe un subdirectorio
branches (al mismo nivel del tronco)
destinado a reunir las ramas etiquetadas
del tronco.
Cada rama recibe el nombre branch.X.X
pg. 10
donde XX es el nombre abreviado del
requerimiento.
Dejar seleccionado HEAD revision para
que la etiqueta tome el estado actual del
tronco.
El comentario asociado a la rama debe
comenzar por la palabra BRANCH y
debe describir el requerimiento que se va
a desarrollar usando la rama.
(Por ejemplo: “BRANCH branch.DB2
creation for supporting DB2 modifying
DAO and ROE assistants”)
En la segunda página confirmar la
creación de la rama dejando seleccionado
que es un Branch.
pg. 11
4.2 TAREAS DEL DESARROLLADOR PARA TRABAJAR EL REQUERIMIENTO EN LA RAMA
Si el desarrollador (o grupo de desarrolladores) que tiene(n) a cargo el requerimiento de hacer una
modificación o extensión al proyecto tiggerRummy realiza las siguientes tareas sobre la rama.
TAREA
RESPONSABLE
ACLARACIONES
Comandos desde el cliente de
Subversion en Eclipse
No se debe hacer una rama
cuando
hay
cambios
pendientes sobre el tronco.
Si es el caso, se debe hacer
commit sobre el tronco
para aplicar los cambios y
luego update.
Aplicar al repositorio asociado al tronco el
comando Checkout
1- TOMAR EL TRONCO
ACTUALIZADO:
Si es la primera vez que se
toma el proyecto
correspondiente al tronco:

Conectarse
al
repositorio
http://197.0.2.24/tigger
Rummy
/technical
(cambiar el IP a
190.25.225.157
por
fuera de la red local)

Hacer un checkout de
este repositorio
El
desarrollador
(o grupo de
desarrolladores
a cargo).
Aplicar al proyecto el comando Team >
Update
Si ya se tiene el proyecto
correspondiente al tronco:

Hacer un update del
proyecto
2- SELECCIONAR LA
RAMA A TRABAJAR
Antes de hacer los cambios
asociados al requerimiento
se debe seleccionar como
proyecto, el asociado a la
rama.
Cada
desarrollador
del grupo que
está a cargo del
cambio.
Aplicar al proyecto el comando Team >
Switch to another Branch/Tag
y escoger el URL asociado a la rama, por
ejemplo:
http://197.0.2.24/tiggerRummy/branches
/branch.DB2
(Dejar seleccionado HEAD revision para ir
al estado actual de la rama)
pg. 12
3- TRABAJAR EN LA
RAMA
A medida que se trabaja en
la rama para realizar la
extensión o modificación
requerida, el desarrollador
debe hacer periódicamente
las siguientes acciones:
a)
Incorporar
los
últimos cambios del
tronco hacia la
rama.
b) Modificaciones y
pruebas de la rama.
c)
En caso de éxito de
las
pruebas,
publicar
los
cambios
en
el
repositorio
haciendo commit de
la rama (no se
afecta el tronco).
El
desarrollador (o
grupo de
desarrolladores
a cargo).
Mientras se construye en la
rama la extensión o
modificación
del
framework no se afecta el
tronco pero sí se tienen en
cuenta los cambios que va
teniendo el tronco.
Al incorporar los cambios
del tronco hacia la rama
pueden surgir conflictos
sobre la rama, los cuales
deben resolverse.
Cuando
son
varios
desarrolladores
en
la
misma
rama,
eventualmente
deben
resolver conflictos entre
ellos cuando hacen commit
en la rama (después de
resolver conflictos utilizar
los comandos commit y
update).
OJO: Tener cuidado de
incorporar cambios del
tronco hacia la rama y no
al revés, colocando un
rango
de
versiones
referentes al tronco.
PARA INCORPORAR CAMBIOS DEL
TRONCO HACIA LA RAMA:
Averiguar cuál es la versión del tronco
correspondiente a la creación de la rama,
mediante el comando Team >Show History
Aplicar al proyecto el comando Team >
Merge : se quiere incorporar a la rama
todos los cambios ocurridos en el tronco
desde la creación de la rama; indicar ese
rango así:
En el From indicar el URL del tronco, por
ejemplo:
http://197.0.2.24/tiggerRummy/technical
y como revisión colocar la correspondiente
a la creación de la rama.
En el To dejar seleccionado “Use From
URL”
y escoger “Head revision”
(significa la versión actual que tiene el
tronco).
Finalmente oprimir el botón “Merge”.
En caso de que resulten archivos con
conflictos (la lista de estos archivos se
indica en la consola ), se debe seleccionar
cada archivo en conflicto y realizar las
siguientes acciones:

Resolver sus conflictos con el
comando Team > Edit conflicts
(para cada conflicto se puede editar el
texto izquierdo que representa el
estado en la máquina del desarrollador,
reemplazar el texto izquierdo por el
derecho que representa el estado en el
repositorio, agregar el texto derecho; al
final debe guardarse el texto izquierdo
para que quite las marcas de conflicto)

Marcar el archivo como resuelto con el
comando Team > Mark Resolved
Cuando se resuelvan todos los conflictos
debe hacerse commit de toda la rama.
NOTA: Las siguientes veces que se
incorporen cambios del tronco hacia la
rama, puede restringirse el rango de
cambios, indicando en el From la version
del tronco que ya se incorporó la última
vez. Utilizar el botón “Show log” para
obtener la lista de versiones del tronco.
pg. 13
4- FIN DEL TRABAJO
EN LA RAMA
Cuando la extensión o
modificación está lista en la
rama, el desarrollador hace
la última incorporación de
cambios del tronco hacia la
rama + pruebas + commit
de la rama y solicita que el
Comité TiggerRummy
incorpore la rama al tronco.
El
desarrollador (o
grupo de
desarrolladores
a cargo) hace la
solicitud al
Comité
TiggerRummy
a través de la
persona que
coordine.
Es el Comité del proyecto
TiggerRummy
el
responsable de modificar el
tronco del proyecto.
pg. 14
4.3 TAREAS DEL RESPONSABLE DE HACER PRUEBAS SOBRE UNA RAMA
Se recomienda que el responsable de hacer pruebas de una rama sea una persona diferente del desarrollador
que trabajó en la rama. Para hacer las pruebas se deben utilizar los siguientes comandos:
TAREA
RESPONSABLE
ACLARACIONES
Comandos desde el cliente de
Subversion en Eclipse
1- TOMAR EL TRONCO
ACTUALIZADO:
Si es la primera vez que se
toma el proyecto
correspondiente al tronco:


Conectarse al
repositorio
http://197.0.2.24/tigger
Rummy /technical
(cambiar el IP a
190.25.225.157 por
fuera de la red local)
Probador
No se debe hacer una
rama cuando hay
cambios
pendientes
sobre el tronco. Si es
el caso, se debe hacer
commit sobre el tronco
para
aplicar
los
cambios
y
luego
update.
Aplicar al repositorio asociado al tronco el
comando Checkout
Hacer un checkout de
este repositorio
Aplicar al proyecto el comando Team > Update
Si ya se tiene el proyecto
correspondiente al tronco:

Hacer un update del
proyecto
El probador
comandos:
2- PRUEBAS DE LA
RAMA
Idealmente el probador debe
ejecutar un deck de pruebas
de regresión (sobre la rama)
que garanticen la
compatibilidad hacia atrás.
Probador
El probador trabaja en
la rama para hacer las
pruebas.
utilizará
los
siguientes
Para seleccionar la rama como el proyecto a
trabaja: aplicar al proyecto el comando:
Team > Switch to another Branch/Tag
y escoger el URL asociado a la rama
(Dejar seleccionado HEAD revision para ir al
estado actual de la rama)
NOTA: Si las pruebas se demoran varios días,
se recomienda incorporar los últimos cambios
del tronco hacia la rama como se indica en la
sección 4.2. Tareas del desarrollador .
pg. 15
4.4 TAREAS DEL ADMINISTRADOR PARA INTEGRAR LA RAMA AL TRONCO
El Administrador es el responsable de modificar el tronco del proyecto, integrando cada rama probada al
tronco.
TAREA
RESPONSABLE
ACLARACIONES
Comandos desde el cliente de
Subversion en Eclipse
1- TOMAR EL TRONCO
ACTUALIZADO:
Si es la primera vez que se
toma el proyecto
correspondiente al tronco:

Conectarse al
repositorio
http://197.0.2.24/tigger
Rummy /technical
(cambiar el IP a
190.25.225.157 por
fuera de la red local)

Aplicar al repositorio asociado al tronco el
comando Checkout
Administrador
del repositorio
No debería haber
cambios pendientes
sobre el tronco,
suponiendo que todo
cambio se maneja en
una rama.
Hacer un checkout de
este repositorio
Aplicar al proyecto el comando Team > Update
Si ya se tiene el proyecto
correspondiente al tronco:

Hacer un update del
proyecto
El Comité de TiggerRummy utilizará los
siguientes comandos:
2- EL
ADMIINISTRADOR
INTEGRA LA RAMA AL
TRONCO
Con la etiqueta del
tronco antes de
integrar la rama se
logra tener una versión
de referencia de cómo
estaba el tronco antes
de la integración.
Si las pruebas de regresión
sobre la rama salieron
exitosas, el Administrador
realiza
las
siguientes
acciones:
a)
Selecciona el tronco
como el proyecto a
trabajar
b) Marca
con
una
etiqueta el tronco
(antes de integración)
c)
Integra la rama al
tronco,
resolviendo
posibles conflictos
d) Marca
etiqueta
con
una
el tronco
Administrador
del repositorio
Con la etiqueta del
tronco después de
integrar la rama se
obtiene la nueva
versión del tronco.
NOTA: se necesita rol
administrador para
crear etiquetas

Si se necesita seleccionar el tronco como el
proyecto a trabajar: usar el comando Team
> Switch to another Branch/Tag
y escoger el URL asociado al tronco
por ejemplo:
http://197.0.2.24/tiggerRummy/technical
(dejar seleccionado HEAD revision para ir
al estado actual del tronco)

Para poner etiquetas sobre el tronco: con el
comando Team > Branch/Tag
En el FROM indicar el URL del tronco:
http://197.0.2.24/tiggerRummy /technical
En el TO indicar el URL de la nueva
etiqueta, por ejemplo:
http://197.0.2.24/tiggerRummy/tags/5.90.00
donde el nombre de la etiqueta se compone
de:
pg. 16
(después
integración)
de
[version].[revision]
.[bugs arreglados]
La revisión actual del repositorio
tiggerRummy/
debe averiguarse antes
mediante el comando Show History usado
en la vista SVN Repository
Dejar seleccionado HEAD revision para
que la etiqueta tome el estado actual del
tronco.
El comentario asociado a la etiqueta debe
comenzar por la palabra TAG e indicar que
es la versión antes o después de integrar la
rama al tronco (por ejemplo: “TAG of
trunk before integrating branch.DB2”)

Para integrar la rama hacia el tronco: con el
comando Team > Merge
En el From indicar el URL de la rama, por
ejemplo:
http://197.0.2.24/tiggerRummy/branches
/branch.DB2
Y como revisión colocar la correspondiente
a la creación de la rama (utilizar el botón
“Show log” para obtener la lista de
versiones de la rama: utilizar el botón “Get
All” para obtener la lista total).
En el To dejar seleccionado “Use From
URL”
y escoger “Head revision”
(significa la versión actual que tiene la
rama).
Finalmente oprimir el botón “Merge”. En
caso de que resulten archivos con conflictos
(la lista de estos archivos se indica en la
consola), se debe seleccionar cada archivo y
realizar la siguientes acciones:
o
Resolver sus conflictos con el
comando Team > Edit conflicts·(el
editor de conflictos muestra en
la parte izquierda la versión del
tronco y en la parte derecha la
versión de la rama).
o
Marcar el archivo como resuelto
con el comando Team > Mark
Resolved
Así no haya conflictos, de todas maneras
debe marcarse como resuelto todo el
proyecto con el comando Team > Mark
pg. 17
Resolved y proceder a hacer commit (de
todo el proyecto).
El comentario del commit debe indicar que
se integró la rama al tronco, por ejemplo:
“INTEGRATION: confirming integration
of branch.DB2 to the trunk”
pg. 18
5 LIBERACIÓN DE CAMBIOS
5.1 VERIFICACIÓN

La nueva versión del proyecto TiggerRummy debe probarse (con el deck de pruebas) antes de liberarse
para los proyectos usuarios.
5.2 METRICS

Se deberían hacer mediciones para cuantificar el cambio que significa la rama.
5.3 CRITERIO DE FINALIZACIÓN

La satisfacción de los proyectos usuarios que utilicen el cambio.
5.4 SALIDAS
Lista de entregables que debe producir el proceso ejecutado:
Entregable
Reporte técnico de la extensión o cambio
realizado al Framework TiggerRummy
Manual para el usuario describiendo cómo
utilizar la extensión o cambio realizado al
Framework TiggerRummy
Aprobación de la extensión o cambio
Responsable
Desarrolladores a cargo
Desarrolladores a cargo
Probadores y Administrador
pg. 19