PROTOCOLO PARA TRABAJAR CON REPOSITORIOS SVN POR MEDIO DE RAMAS

Autores: MARIA CONSUELO FRANKY JOHN EDDIE DAZ AGUDELO JUAN FELIPE OLAYA

PONTIFICIA UNIVERSIDAD JAVERIANA DEPARTAMENTO DE INGENIERA DE SISTEMAS CARRERA DE INGENIERA DE SISTEMAS BOGOT D.C. 2010.

Tabla de Contenido
1 1.1 2 2.1 2.2 2.3 2.4 3 3.1 3.2 3.3 4 4.1 4.2 4.3 4.4 PRELIMINARES.........................................................................................................................................................3 TRMINOS USADOS ..................................................................................................................................................3 INSTALACIN Y ADMINISTRACION DE SUBVERSION .................................................................................4 INSTALACIN DE SUBVERSION .................................................................................................................................4 CREACIN DE UN REPOSITORIO SUBVERSION ...........................................................................................................4 ADMINISTRACIN DE USUARIOS, PERMISOS Y BACKUPS DE UN REPOSITORIO SUBVERSION ......................................5 INSTALACIN DEL PLUGIN SUBVERSION PARA ECLIPSE ............................................................................................6 RECOMENDACIONES IMPORTANTES ...............................................................................................................7 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 INTEGRACIN DE LAS RAMAS AL TRONCO ........................................................7 PROTOCOLO DE TAREAS ......................................................................................................................................9 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 .......................................................................14 TAREAS DEL ADMINISTRADOR PARA INTEGRAR LA RAMA AL TRONCO ...................................................................15

pg. 2

1 PRELIMINARES
El objetivo del presente documento es dar guas de uso del manejador de version Subversion, incluyendo el manejo de actividades en ramas paralelas. Para que estas guas conduzcan a un manejo correcto de las versiones de software de un proyecto, los desarrolladores deben adoptarlas como disciplina de trabajo desde el inicio del proyecto. En este documento se utilizar como ejemplo un proyecto denominado tiggerRummy.

1.1 TRMINOS USADOS

Versin: Estado de un conjunto de clases (y de otro tipo de archivos) que forman un sistema o componente. El conjunto de clases forman una versin en un momento dado. Versin en produccin: Es una versin de un sistema o componente que se encuentra disponible para el uso de usuarios finales. Versin en desarrollo: Versin de un sistema o componente que est sufriendo modificaciones por mejoras o correcciones por lo que an no est disponible para produccin. Tronco: Es un trmino equivalente a la versin estable oficial de desarrollo del sistema. Rama (Branch): Versin de desarrollo paralela a la versin oficial (tronco) que se trabaja hasta tenerla lista para salir a pruebas y posterior produccin. Ambas versiones, la oficial y la rama comparten un ancestro comn y estn destinadas a converger en el futuro cercano. Para mltiples desarrollos paralelos se debe crear una rama para cada uno de ellos y luego integrarlos secuencialmente al tronco. Etiqueta (Tag): Copia de la versin oficial tomada en cierto momento. A diferencia de las ramas, las versiones con etiquetas no deberan sufrir modificaciones. Directorios del tronco, de ramas y de etiquetas: para el repositorio tiggerRummy se tienen los siguientes directorios: tiggerRummy/trunk: Directorio del tronco tiggerRummy/branches: Directorio de ramas tiggerRummy/tags: Directorio de etiquetas

o o o

pg. 3

2 INSTALACIN Y ADMINISTRACION DE SUBVERSION

2.1 INSTALACIN 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 tambin instalan Subversion (y CVS).

2.2 CREACIN DE UN REPOSITORIO SUBVERSION

Suponiendo que el directorio raz de instalacin de Subversion es: /datos/svn.repository/ la creacin 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, aadiendo la siguiente seccin (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 ADMINISTRACIN
SUBVERSION

DE USUARIOS, PERMISOS Y BACKUPS DE UN REPOSITORIO

La persona encargada de las labores administrativas del repositorio, puede remitirse al manual de Subversion: version control with subversin.pdf localizado en la siguiente ubicacin dentro del CD de ConstruColectiva: /Guia/Anexos/version control with subversin.pdf Es importante restringir en los permisos que solo usuarios con el rol de administrador puedan modificar el tronco del repositorio (para creacin e integracin de nuevas ramas al tronco). Los comandos ms frecuentes se ilustran a continuacin: Definicin 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 (exportacin): cd /datos/svn.repository/ svnadmin dump /datos/svn.repository/tiggerRummy > tiggerRummy2009-12-30.dmp Este backup puede importarse a un repositorio vaco (en la misma mquina o en otra mquina): svnadmin create newtiggerRummy svnadmin load newtiggerRummy < tiggerRummy-2008-03-30.dmp

pg. 5

2.4 INSTALACIN 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 darn 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 pgina web: http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA A continuacin se resumen los puntos importantes de esta instalacin: 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 (Podran integrarse las ventanas de esta perspectiva a la perspectiva Team) 5- Definir acceso a repositorio Subversion: Indicar URL, usuario/password Ejemplo: http://myserver.com.co/tiggerRummy http://myserver.com.co/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 versin 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 integracin deben llevar los cambios ocurridos en todo el tronco hacia una rama o integrar toda una rama hacia el tronco. Despus de estas integraciones debe hacerse un commit de toda la rama o de todo el tronco, segn el caso. Las etiquetas representan versiones del tronco antes de la creacin de una rama; tambin antes y despus de la integracin de la rama al tronco.

3.2 REGISTRAR BUENOS COMENTARIOS CON LOS COMANDOS SUBVERSION

Los comandos Subversion requieren un comentario. Para los comandos de creacin de ramas, etiquetas e integraciones se recomienda configurar o seleccionar los templates de comentarios que ya estn 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 genrico que no da informacin (ej: fixing problem).

3.3 MINIMIZAR LOS CONFLICTOS EN LA INTEGRACIN DE LAS RAMAS AL TRONCO

Despus de cada integracin 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
pg. 7

las ramas se mantienen actualizadas respecto al tronco y se reduce la probabilidad de que ocurran conflictos en la integracin de una prxima rama al tronco. Para cada integracin de una rama al tronco debe obtenerse el log de integracin y agregarle como se resolvieron los conflictos, si los hubo. El administrador enva este log al responsable de la rama integrada para que confirme si fue correcta la resolucin de conflictos. Otra prctica adicional para minimizar conflictos es que el administrador no integre varias ramas al tronco en forma consecutiva sino que permita despus de cada integracin que los desarrolladores actualicen sus ramas activas, antes de proceder a una siguiente integracin de otra rama al tronco. En general no deberan 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 modificacin o extensin al proyecto TiggerRummy, debe solicitar al Administrador del repositorio la creacin de una rama a partir del tronco (por poltica de permisos solo usuarios con rol administrador en el repositorio pueden crear ramas).
TAREA
1- TOMAR EL TRONCO ACTUALIZADO: Si es la primera vez que se toma el proyecto correspondiente al tronco: Conectarse al repositorio: http://myserver.com.co/ tiggerRummy /trunk Hacer un checkout de este repositorio Aplicar al proyecto el comando Team > Update

RESPONSABLE
Administrador del repositorio

ACLARACIONES
No debera haber cambios pendientes sobre el tronco, suponiendo que todo cambio se maneja en una rama.

Comandos desde el cliente de Subversion en Eclipse

Aplicar al repositorio asociado al tronco el comando Checkout

Si ya se tiene el proyecto correspondiente al tronco: Hacer un update del proyecto Administrador del repositorio Con la etiqueta se logra tener una versin de referencia de cmo estaba el tronco antes de la extensin o modificacin. Para crear una etiqueta se necesita rol de administrador.

2- MARCAR LA VERSION ACTUAL DEL TRONCO CON UNA ETIQUETA

Averiguar cul es la revisin actual del repositorio mediante el comando: Show History, usado en la vista SVN Repository (notar que es la revisin del repositorio tiggerRummy/ y no nicamente del tronco tiggerRummy/trunk/ 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://myserver.com.co/tiggerRummy /trunk En el TO indicar el URL de la nueva etiqueta, por ejemplo:

pg. 9

http://myserver.com.co/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 recibe un nombre compuesto de : [version].[revision].[bugs arreglados] Donde : [version] Es la versin mayor del producto del proyecto [revision] Es la revisin actual del tronco [bugs arreglados] Es el nmero de bugs arreglados en la versin 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 algn problema. En el ejemplo 5.81.00 nos referimos a la versin 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 versin antes de crear la rama en donde se har el cambio (por ejemplo: TAG of trunk before creating branch01.DB2). 3- ABRIR UNA RAMA A PARTIR DEL TRONCO: Administrador del repositorio Slo un administrador rama. usuario crea la Aplicar al proyecto el comando Team > Branch/Tag En el FROM indicar el URL del tronco: http://myserver.com.co/tiggerRummy /trunk En el TO indicar el URL de la nueva rama, por ejemplo: http://myserver.com.co/tiggerRummy/bra nches /branch01.DB2 Observar que existe un subdirectorio branches (al mismo nivel del tronco) destinado a reunir las ramas etiquetadas del tronco.

pg. 10

Cada rama recibe el nombre branchNN.X.X donde NN es el consecutivo cronolgico de la rama y 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 branch01.DB2 creation for supporting DB2) En la segunda pgina confirmar la creacin 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 modificacin o extensin al proyecto tiggerRummy realiza las siguientes tareas sobre la rama. TAREA
1- TOMAR EL TRONCO ACTUALIZADO: Si es la primera vez que se toma el proyecto correspondiente al tronco: Conectarse al repositorio http://myserver.com.co/ tiggerRummy /trunk Hacer un checkout de este repositorio Aplicar al proyecto el comando Team > Update

RESPONSABLE
El desarrollador (o grupo de desarrolladores a cargo).

ACLARACIONES
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.

Comandos desde el cliente de Subversion en Eclipse

Aplicar al repositorio asociado al tronco el comando Checkout

Si ya se tiene el proyecto correspondiente al tronco: Hacer un update del proyecto Cada desarrollador del grupo que est a cargo del cambio.

2- SELECCIONAR LA RAMA A TRABAJAR Antes de hacer los cambios asociados al requerimiento se debe seleccionar como proyecto, el asociado a la rama. 3- TRABAJAR EN LA RAMA A medida que se trabaja en la rama para realizar la extensin o modificacin requerida, el desarrollador debe hacer peridicamente las siguientes acciones: a) Incorporar los ltimos cambios del tronco hacia la rama.

Aplicar al proyecto el comando Team > Switch to another Branch/Tag y escoger el URL asociado a la rama, por ejemplo: http://myserver.com.co/tiggerRummy /branches /branch01.DB2

El desarrollador (o grupo de desarrolladores a cargo).

Mientras se construye en la rama la extensin o modificacin del proyecto 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.

(Dejar seleccionado HEAD revision para ir al estado actual de la rama) PARA INCORPORAR CAMBIOS DEL TRONCO HACIA LA RAMA: Averiguar cul es la versin del tronco correspondiente a la creacin 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 creacin de la rama; indicar ese rango as: En el From indicar el URL del tronco, por ejemplo:

pg. 12

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).

Cuando son varios desarrolladores en la misma rama, eventualmente deben resolver conflictos entre ellos cuando hacen commit en la rama (despus de resolver conflictos utilizar los comandos commit y update). OJO: Tener cuidado de incorporar cambios del tronco hacia la rama y no al revs, colocando un rango de versiones referentes al tronco.

http://myserver.com.co/tiggerRummy/trunk y como revisin colocar la correspondiente a la creacin de la rama. En el To dejar seleccionado Use From URL y escoger Head revision (significa la versin actual que tiene el tronco). Finalmente oprimir el botn 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 mquina 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 botn Show log para obtener la lista de versiones del tronco.

4- FIN DEL TRABAJO EN LA RAMA Cuando la extensin o modificacin est lista en la rama, el desarrollador hace la ltima incorporacin de cambios del tronco hacia la rama + pruebas + commit de la rama y solicita que el Administrador del repositorio incorpore la rama al tronco. El desarrollador (o grupo de desarrolladores a cargo) hace la solicitud al Administrador del repositorio.

Es el Administrador del repositorio el responsable de modificar el tronco del proyecto.

pg. 13

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
1- TOMAR EL TRONCO ACTUALIZADO: Si es la primera vez que se toma el proyecto correspondiente al tronco: Conectarse al repositorio http://myserver.com.co/ tiggerRummy /trunk Hacer un checkout de este repositorio Aplicar al proyecto el comando Team > Update 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.

RESPONSABLE

ACLARACIONES

Comandos desde el cliente de Subversion en Eclipse

Aplicar al repositorio asociado al tronco el comando Checkout

Probador

Si ya se tiene el proyecto correspondiente al tronco: Hacer un update del proyecto

2- PRUEBAS DE LA RAMA Idealmente el probador debe ejecutar un deck de pruebas de regresin (sobre la rama) que garanticen la compatibilidad hacia atrs.

El probador comandos:

utilizar

los

siguientes

Probador

El probador trabaja en la rama para hacer las pruebas.

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 das, se recomienda incorporar los ltimos cambios del tronco hacia la rama como se indica en la seccin 4.2. Tareas del desarrollador .

pg. 14

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
1- TOMAR EL TRONCO ACTUALIZADO: Si es la primera vez que se toma el proyecto correspondiente al tronco: Conectarse al repositorio http://myserver.com.co/ tiggerRummy /trunk Hacer un checkout de este repositorio Aplicar al proyecto el comando Team > Update

RESPONSA ACLARACI -BLE O-NES

Administrador del repositorio No debera haber cambios pendientes sobre el tronco, suponiendo que todo cambio se maneja en una rama.

Comandos desde el cliente de Subversion en Eclipse

Aplicar al repositorio asociado al tronco el comando Checkout

Si ya se tiene el proyecto correspondiente al tronco: Hacer un update del proyecto 2- EL ADMIINISTRADOR INTEGRA LA RAMA AL TRONCO Si las pruebas de regresin sobre la rama salieron exitosas, el Administrador realiza las siguientes acciones: a) Selecciona el tronco como el proyecto a trabajar

Administrador del repositorio

Con la etiqueta del tronco antes de integrar la rama se logra tener una versin de referencia de cmo estaba el tronco antes de la integracin. Con la etiqueta del tronco despus de integrar la rama se obtiene la nueva versin del tronco. NOTA: se necesita rol administrador para crear etiquetas

El Comit de TiggerRummy utilizar los siguientes comandos: 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://myserver.com.co/tiggerRummy/trunk (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://myserver.com.co/tiggerRummy /trunk En el TO indicar el URL de la nueva etiqueta, por ejemplo: http://myserver.com.co/tiggerRummy/tags /5.90.00 donde el nombre de la etiqueta se compone de: [version].[revision] .[bugs arreglados]

b) Marca con una etiqueta el tronco (antes de integracin) c) Integra la rama al tronco, resolviendo posibles conflictos

d) Marca con una etiqueta el tronco (despus de integracin)

pg. 15

La revisin 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 versin antes o despus de integrar la rama al tronco (por ejemplo: TAG of trunk before integrating branch01.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://myserver.com.co/tiggerRummy /branches /branch01.DB2 Y como revisin colocar la correspondiente a la creacin de la rama (utilizar el botn Show log para obtener la lista de versiones de la rama: utilizar el botn Get All para obtener la lista total). En el To dejar seleccionado Use From URL y escoger Head revision (significa la versin actual que tiene la rama). Finalmente oprimir el botn 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 versin del tronco y en la parte derecha la versin de la rama). 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 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 branch01.DB2 to the trunk

pg. 16