De vez en cuando, obtendrá un conflicto cuando actualice/fusione sus archivos desde el repositorio o cuando cambie su copia de trabajo a una URL diferente. Hay dos tipos de conflictos:
Un conflicto de archivo ocurre si dos (o más) desarrolladores han cambiado las mismas líneas de un archivo.
Un conflicto de árbol ocurre cuando un desarrollador mueve/renombra/elimina un archivo o una carpeta, que otro desarrollador también ha movido/renombrado/borrado, o quizás lo haya modificado.
A file conflict occurs when two or more developers have changed the same few lines of a file. As Subversion knows nothing of your project, it leaves resolving the conflicts to the developers. The conflicting area in a text file is marked like this:
<<<<<<< filename
your changes
=======
code merged from repository
>>>>>>> revision
Also, for every conflicted file Subversion places three additional files in your directory:
Este es su archivo tal y como estaba en su copia de trabajo antes que actualizara su copia de trabajo - esto es, sin marcadores de conflicto. Este archivo tiene sus últimos cambios en él y nada más.
Este es el archivo que era la revisión BASE antes que actualizara su copia de trabajo. Esto es, el archivo que obtuvo antes de empezar a hacer sus últimos cambios.
Este es el archivo que su cliente de Subversion acaba de recibir desde el servidor del que actualizó su copia de trabajo. Este archivo corresponde a la revisión HEAD del repositorio.
Puede lanzar una herramienta de fusión / editor de conflictos externo con → o puede usar cualquier editor de texto para resolver el conflicto manualmente. Debe decidir cómo debe quedar finalmente el código, hacer los cambios necesarios y guardar el fichero. Usando una herramienta de fusión como TortoiseMerge o cualquier otra herramienta popular es normalmente la mejor opción ya que generalmente presentan los ficheros en una vista de 3 paneles y no tiene que preocuparse de las marcas de conflicto. Si usa un editor de texto entonces debe buscar las líneas que comiencen con el literal <<<<<<<.
Después, ejecute el comando → y confirme sus modificaciones al repositorio. Tome nota que el comando Resolver realmente no resuelve el conflicto. Simplemente elimina los archivos filename.ext.mine y filename.ext.r*, dejándole confirmar sus cambios.
Si tiene conflictos con archivos binarios, Subversion no intentará mezclar dichos archivos por si mismo. El archivo local se mantendrá sin cambios (exactamente tal y como lo había cambiado usted) y obtendrá unos archivos nombrefichero.ext.r*. Si desea descartar sus cambios y quedarse con la versión del repositorio, utilice el comando Revertir. Si desea mantener su versión y sobreescribir la versión del repositorio, utilice el comando Resuelto y luego confirme su versión.
Puede utilizar el comando Resuelto para múltiples archivos si pulsa con el botón derecho en la carpeta padre y selecciona → Esto mostrará un diálogo con todos los archivos en conflicto dentro de esa carpeta, y le permitirá seleccionar cuáles marcar como resueltos.
Un conflicto de propiedades ocurre si dos (o más) desarrolladores han cambiado la misma propiedad. Como con los conflictos de archivos, resolver el conflicto solo puede ser hecho por los desarrolladores.
Si uno de los cambios debe sobreescribir al otro entonces seleccione la opción Resolver usando la propiedad local o Resolver usando la propiedad remota. Si los cambios deben ser fusionados entonces seleccione Editar propiedad manualmente, resuelva cuál debiera ser el valor de la propiedad y marque como resuelto.
Un conflicto de árbol ocurre cuando un desarrollador mueve/renombra/elimina un archivo o una carpeta, que otro desarrollador también ha movido/renombrado/borrado, o quizás lo haya modificado. Hay diferentes situaciones que puede resultar en un conflicto de árbol, y todas ellas requiere pasos diferentes para resolver el conflicto.
Cuando se elimina un archivo de forma local en Subversion, el archivo también se elimina del sistema local de archivos, por lo que incluso si es parte de un conflicto de árbol no se puede mostrar un ícono superpuesto de conflicto y no puede hacer clic con el botón derecho sobre él para resolver el conflicto. En este caso, utilice el diálogo Comprobar modificaciones para acceder a la opción Editar conflictos.
TortoiseSVN puede ayudarle a encontrar el lugar correcto para fusionar los cambios, pero puede que necesite realizar un trabajo adicional para arreglar los conflictos. Recuerde que tras una actualización la BASE de trabajo siempre contendrá la revisión de cada ítem tal y como estaba en el repositorio en el momento de la actualización. Si revierte un cambio tras la actualización, se revierte a su estado del repositorio, no a como estaba cuando empezó a hacer sus propios cambios locales.
El desarrollador A modifica Foo.c y lo confirma en el repositorio.
El desarrollador B al mismo tiempo ha movido Foo.c a Bar.c en su propia copia de trabajo, o simplemente ha borrado Foo.c o su carpeta padre.
Una actualización de la copia de trabajo del desarrollador B acaba con un conflicto de árbol:
Foo.c ha sido borrado de la copia de trabajo, pero está marcado como un conflicto de árbol.
Si el conflicto aparece después de un renombrado en vez de un borrado, entonces Bar.c está marcado como añadido, pero no contiene las modificaciones del desarrollador A.
El desarrollador B ahora tiene que elegir si mantiene los cambios realizados por el desarrollador A. En el caso de un renombrado, puede fusionar los cambios de Foo.c dentro del archivo renombrado Bar.c. Para simples borrados de archivos o directorios puede elegir quedarse con los cambios del ítem del desarrollador A y descartar el borrado. O, si marca el conflicto como resuelto sin hacer nada más, estará descartando los cambios del desarrollador A.
The conflict edit dialog offers to merge changes if it can find the original file of the renamed Bar.c. If there are multiple files that are possible move sources, then a button for each of these files is shown which allow you to chose the correct file.
El desarrollador A mueve Foo.c a Bar.c y lo confirma en el repositorio.
El desarrollador B modifica Foo.c en su copia de trabajo.
O en el caso de mover una carpeta...
El desarrollador A mueve la carpeta padre FooFolder a BarFolder y lo confirma en el repositorio.
El desarrollador B modifica Foo.c en su copia de trabajo.
Una actualización de la copia de trabajo de B acaba con un conflicto de árbol. Para un conflicto simple de archivo:
Bar.c se añade a la copia de trabajo como un archivo normal.
Foo.c se marca como añadido (con historia) y tiene un conflicto de árbol.
Para un conflicto de carpeta:
BarFolder se añade a la copia de trabajo como una carpeta normal.
FooFolder se marca como añadida (con historia) y tiene un conflicto de árbol.
Foo.c se marca como modificado.
El desarrollador B tiene ahora que decidir si desea continuar con la reorganización del desarrollador A y fusionar sus cambios en los archivos correspondientes de la nueva estructura, o simplemente revertir los cambios de A y mantener el archivo local.
To merge her local changes with the reshuffle, Developer B must first find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog. Then use the button which shows the correct source file to resolve the conflict.
If Developer B decides that A's changes were wrong then she must choose the Mark as resolved button in the conflict editor dialog. This marks the conflicted file/folder as resolved, but Developer A's changes need to be removed by hand. Again the log dialog helps to track down what was moved.
El desarrollador A mueve Foo.c a Bar.c y lo confirma en el repositorio.
El desarrollador B mueve Foo.c a Bix.c.
Una actualización de la copia de trabajo del desarrollador B acaba con un conflicto de árbol:
Bix.c se marca como añadido con historia.
Bar.c se añade a la copia de trabajo con el estado 'normal'.
Foo.c se marca como borrado y tiene un conflicto de árbol.
Para resolver este conflicto, el desarrollador B tiene que averiguar qué nombre de archivo tiene ahora el archivo en conflicto Foo.c que fue renombrado/movido en el repositorio. Esto puede hacerse utilizando el diálogo de registro.
Luego el desarrollador B tiene que decidir qué nuevo nombre de archivo de Foo.c mantiene - el del desarrollador A o el renombrado que hizo él mismo.
Después que el desarrollador B haya resuelto manualmente el conflicto, el conflicto de árbol debe marcarse como resuelto mediante el botón del diálogo de editar conflictos.
El desarrollador A, que está trabajando en el tronco, modifica Foo.c y lo confirma en el repositorio
El desarrollador B, que está trabajando en una rama, mueve Foo.c a Bar.c y lo confirma en el repositorio
Una fusión de los cambios en el tronco del desarrollador A con los cambios de la copia de trabajo de la rama del desarrollador B acaba con un conflicto de árbol:
Bar.c ya está en la copia de trabajo con estado 'normal'.
Foo.c se marca como faltante con un conflicto de árbol.
Para resolver este conflicto, el desarrollador B tiene que marcar el archivo como resuelto en el diálogo de edición de conflictos, lo que lo eliminará de la lista de conflictos. Luego tendrá que decidir si copia el archivo faltante Foo.c desde el repositorio a la copia de trabajo, si fusiona los cambios del desarrollador A hechos a Foo.c en el archivo renombrado Bar.c, o si desea ignorar los cambios marcando el conflicto como resuelto y no haciendo nada más.
Tenga en cuenta que si copia el archivo faltante desde el repositorio y luego marca como resuelto, su copia de eliminará de nuevo. Tiene que resolver el conflicto antes.
El desarrollador A, que está trabajando en el tronco, mueve Foo.c a Bar.c y lo confirma en el repositorio.
El desarrollador B, que está trabajando en una rama, modifica el archivo Foo.c y lo confirma en el repositorio.
El desarrollador A, que está trabajando en el tronco, mueve la carpeta padre FooFolder a BarFolder y lo confirma en el repositorio.
El desarrollador B, que está trabajando en un rama, modifica Foo.c en su copia de trabajo.
Una fusión de los cambios en el tronco del desarrollador A con los cambios de la copia de trabajo de la rama del desarrollador B acaba con un conflicto de árbol:
Bar.c se marca como añadido.
Foo.c se marca como modificado con un conflicto de árbol.
El desarrollador B tiene ahora que decidir si desea continuar con la reorganización del desarrollador A y fusionar sus cambios en los archivos correspondientes de la nueva estructura, o simplemente revertir los cambios de A y mantener el archivo local.
To merge her local changes with the reshuffle, Developer B must first find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog for the merge source. The conflict editor only shows the log for the working copy as it does not know which path was used in the merge, so you will have to find that yourself. The changes must then be merged by hand as there is currently no way to automate or even simplify this process. Once the changes have been ported across, the conflicted path is redundant and can be deleted.
If Developer B decides that A's changes were wrong then she must choose the Mark as resolved button in the conflict editor dialog. This marks the conflicted file/folder as resolved, but Developer A's changes need to be removed by hand. Again the log dialog for the merge source helps to track down what was moved.
El desarrollador A, que está trabajando en el tronco, mueve Foo.c a Bar.c y lo confirma en el repositorio.
El desarrollador B, que está trabajando en una rama, mueve Foo.c a Bix.c y lo confirma en el repositorio.
Una fusión de los cambios en el tronco del desarrollador A con los cambios de la copia de trabajo de la rama del desarrollador B acaba con un conflicto de árbol:
Bix.c se marca con el estado normal (no modificado).
Bar.c se marca como añadido con historia.
Foo.c se marca como faltante con un conflicto de árbol.
To resolve this conflict, Developer B has to find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog for the merge source.
Luego el desarrollador B tiene que decidir qué nuevo nombre de archivo de Foo.c mantiene - el del desarrollador A o el renombrado que hizo él mismo.
Después que el desarrollador B haya resuelto manualmente el conflicto, el conflicto de árbol debe marcarse como resuelto mediante el botón del diálogo de editar conflictos.
Hay otros casos etiquetados como conflictos de árboles simplemente porque el conflicto implica un directorio en vez de un archivo. Por ejemplo, si añade un directorio con el mismo nombre tanto al tronco como a la rama y trata de fusionarlos obtendrá un conflicto de árbol. Si quiere mantener el directorio del objetivo de la fusión, marque el conflicto como resuelto. Si quiere usar el de la fuente de fusión, entonces necesita primero hacer un SVN delete para borrar el directorio del objetivo y volver a lanzar la fusión. Si necesita algo más complejo deberá hacerlo manualmente.