¿Por qué tengo conflictos de árboles en Subversion?

Subversion 1.6 agregó Conflictos de árbol para cubrir conflictos a nivel de directorio. Un buen ejemplo sería cuando se elimina localmente un archivo a continuación, una actualización intenta traer un cambio de texto en ese archivo. Otra es cuando tiene un Cambio de nombre de subversion de un archivo que está editando ya que es una acción de Agregar/Eliminar.

El blog de Subversion de CollabNet tiene un gran artículo sobre Conflictos de árbol.

En mi experiencia, SVN crea un conflicto de árbol CADA VEZ que elimino una carpeta. Parece que no hay razón.

Soy el único que trabaja en mi código - > eliminar un directorio - > confirmar - > conflicto!

No puedo esperar para cambiar a Git.

Debo aclarar - Utilizo Subclipse. ¡Ese es probablemente el problema! Una vez más, no puedo esperar para cambiar...

No se si esto te está pasando, pero a veces elijo el directorio equivocado para fusionar y obtengo este error a pesar de que todos los archivos aparecen completamente bien.

Ejemplo:

Merge / svn / Project/branches/some-branch / Sources a / svn / Project / trunk - - - > Tree conflict

Merge / svn / Project / branches / some-branch a / svn / Project / trunk - - - > OK

Esto puede ser un error estúpido, pero no siempre es obvio porque crees que es algo más complicado.

Lo que está sucediendo aquí es lo siguiente: Crea un nuevo archivo en su tronco, luego lo fusiona en su rama. En la confirmación de fusión este archivo se creará también en tu rama.

Cuando usted fusiona su rama de nuevo en el tronco, SVN intenta hacer lo mismo de nuevo: Ve que un archivo fue creado en su rama, y trata de crearlo en su tronco en la confirmación de fusión, pero ya existe! Esto crea un conflicto de árbol.

La manera de evitar esto, es hacer una fusión especial, un reintegración. Puede lograr esto con el interruptor --reintegrate.

Puede leer sobre esto en la documentación: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

Al fusionar su rama de nuevo al tronco, sin embargo, el subyacente las matemáticas son muy diferentes. Tu rama de características ahora es una mezcolanza tanto de los cambios de tronco duplicados como de los cambios de rama privada, no hay nada simple rango contiguo de revisiones a copiar. Por especificando la opción reinteg reintegrate, le está pidiendo a Subversion que replique cuidadosamente solo los cambios exclusivos de su rama. (Y en de hecho, lo hace comparando el último árbol de tronco con el último árbol de ramas: la diferencia resultante es exactamente sus cambios de ramas!)

Después de reintegrar una rama, es muy recomendable eliminarla, de lo contrario, seguirá recibiendo treeconflicts cada vez que se fusione en la otra dirección: desde el tronco hasta la rama. (Por exactamente la misma razón que se describió antes.)

También hay una manera de evitar esto, pero nunca lo intenté. Puedes leerlo en este post: Reintegración de ramas de Subversion en v1.6

Esto puede ser causado por no usar los mismos clientes de versión en todas partes.

Usar un cliente versión 1.5 y un cliente versión 1.6 hacia el mismo repositorio puede crear este tipo de problema. (Me mordieron a mí mismo.)

Si encuentra conflictos de árbol que no tienen sentido porque no editó/eliminó/se acercó al archivo, también hay una buena probabilidad de que haya un error en el comando merge.

Lo que puede suceder es que ya haya fusionado previamente un montón de cambios que está incluyendo en su fusión actual. Por ejemplo, en el tronco alguien editó un archivo, y luego lo renombró. Si en su primera fusión incluye la edición, y luego en una segunda fusión incluir tanto la edición y el cambio de nombre (esencialmente un quitar), también le dará un conflicto de árbol. La razón de esto es que la edición previamente fusionada aparece como suya, y por lo tanto la eliminación no se realizará automáticamente.

Esto puede ocurrir en repositorios 1.4 al menos, no estoy seguro de si el mergetracking introducido en 1.5 ayuda aquí.

También me encontré con este problema hoy, aunque mi problema en particular probablemente no esté relacionado con el tuyo. Después de inspeccionar la lista de archivos, me di cuenta de lo que había hecho temporarily había estado usando temporalmente un archivo en un ensamblado de otro ensamblado. He hecho muchos cambios en él y no quería huérfano el historial SVN, por lo que en mi rama había movido el archivo desde la carpeta del otro ensamblador. Esto no es rastreado por SVN, por lo que solo parece que el archivo se elimina y luego se vuelve a agregar. Esto termina causando un conflicto de árboles.

Resolví el problema moviendo el archivo de nuevo, confirmando, y luego fusionando mi rama. Luego moví el archivo de nuevo después. :) Que parecía hacer el truco.

Tuve un problema similar. Lo único que realmente funcionó para mí fue eliminar los subdirectorios en conflicto con:

svn delete --force ./SUB_DIR_NAME

Luego cópielos de nuevo desde otro directorio raíz en la copia de trabajo que los tiene con:

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

Entonces haga

svn cleanup

Y

svn add *

Puede que recibas advertencias con la última, pero simplemente ignóralas y finalmente

svn ci .

Tuve este mismo problema, y lo resolví re-haciendo la fusión usando estas instrucciones. Básicamente, utiliza la "combinación de 2 URL" de SVN para actualizar trunk al estado actual de su rama, sin molestarse tanto en el historial y los conflictos de árbol. Me salvó de arreglar manualmente 114 conflictos de árbol.

No estoy seguro de si conserva la historia tan bien como uno quisiera, pero valió la pena en mi caso.

Un escenario con el que a veces me encuentro:

Supongamos que tiene un tronco, desde el cual creó una rama release. Después de algunos cambios en el tronco (en particular creando el directorio "some-dir"), se crea una rama feature/fix que se desea fusionar posteriormente en la rama release también (porque los cambios fueron lo suficientemente pequeños y la característica/fix es importante para release).

trunk -- ... -- create "some-dir" -- ...
     \                                  \-feature/fix branch
      \- release branch

Si luego intenta fusionar la rama feature/fix directamente en la rama release, obtendrá un conflicto de árbol (aunque el directorio ni siquiera existía en la rama feature/fix):

svn status
!     C some-dir
      >   local missing or deleted or moved away, incoming file edit upon merge

Así que necesita fusionar explícitamente las confirmaciones que se hicieron en trunk antes de crear la rama feature/fix que creó el directorio "some-dir" antes de fusionar la rama feature/fix.

A menudo lo olvido ya que no es necesario en git.