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

Tenía una rama característica de mi tronco y fusionaba cambios de mi tronco a mi rama periódicamente y todo funcionaba bien. Hoy fui a fusionar la rama nuevamente en el tronco y cualquiera de los archivos que se agregaron a mi tronco después de la creación de mi rama se marcaron como un "conflicto de árbol". ¿Hay alguna manera de evitar esto en el futuro?

No creo que se estén marcando correctamente.

Encontré la solución leyendo el enlace que Gary dio (y sugiero seguirlo de esta manera).

Resumiendo para resolver el conflicto del árbol que compromete su directorio de trabajo con el cliente SVN 1.6.x, puede usar:

svn resolve --accept working -R .

donde .está el directorio en conflicto

ADVERTENCIA : "Confirmar su directorio de trabajo" significa que su estructura de sandbox será la que usted está comprometiendo, por lo que si, por ejemplo, eliminó algún archivo de su sandbox, también se eliminarán del repositorio. Esto se aplica solo al directorio en conflicto.

De esta manera, le sugerimos a SVN que resuelva el conflicto ( --resolve), aceptando la copia de trabajo dentro de su sandbox ( --accept working), recursivamente ( -R), comenzando desde el directorio actual ( .).

En TortoiseSVN, al seleccionar "Resuelto" con el botón derecho, se resuelve este problema.

Subversion 1.6 agregó Tree Conflicts para cubrir conflictos en el nivel de directorio. Un buen ejemplo sería cuando elimina localmente un archivo y luego una actualización intenta reducir el cambio de texto en ese archivo. Otra es cuando tiene una subversión Cambiar el nombre de un archivo que está editando, ya que es una acción Agregar / Eliminar.

El blog de Subversion de CollabNet tiene un excelente artículo sobre Conflictos de árboles .

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

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

No puedo esperar para cambiar a Git .

Debo aclarar: uso Subclipse . ¡Ese es probablemente el problema! De nuevo, no puedo esperar para cambiar ...

No sé si esto le está sucediendo, pero a veces elijo el directorio incorrecto para fusionar y obtengo este error a pesar de que todos los archivos aparecen completamente bien.

Ejemplo:

Fusionar / svn / Project / sucursales / some-branch / Fuentes a / svn / Project / trunk ---> Tree conflict

Fusionar / svn / Project / sucursales / some-branch a / svn / Project / trunk ---> OK

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

Lo que sucede aquí es lo siguiente: crea un nuevo archivo en su troncal, luego lo combina en su rama. En la confirmación de fusión, este archivo también se creará en su rama.

Cuando fusiona su rama nuevamente en el tronco, SVN intenta hacer lo mismo nuevamente: ve que se creó un archivo en su rama e intenta crearlo en su tronco en la confirmación de fusión, ¡pero ya existe! Esto crea un conflicto de árbol.

La forma de evitar esto es hacer una fusión especial, una reintegración . Puede lograr esto con el --reintegrateinterruptor.

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

Sin embargo, al fusionar su rama con el tronco, las matemáticas subyacentes son bastante diferentes. Su rama de características ahora es una mezcla de cambios de troncales duplicados y cambios de ramas privadas, por lo que no hay un rango contiguo simple de revisiones para copiar. Al especificar la opción --reintegrate, le está pidiendo a Subversion que replique cuidadosamente solo aquellos cambios exclusivos de su rama. (Y de hecho, hace esto comparando el último árbol de tronco con el último árbol de rama: ¡la diferencia resultante es exactamente los cambios de rama!)

Después de reintegrar una rama, es muy recomendable eliminarla, de lo contrario, seguirá teniendo conflictos de árbol cada vez que se una en la otra dirección: desde el tronco hasta su rama. (Por exactamente el mismo motivo descrito anteriormente).

También hay una forma de evitar esto, pero nunca lo intenté. Puede leerlo en esta publicación: Reintegración de la rama Subversion en v1.6

Esto puede ser causado por no usar la misma versión de clientes por todas partes.

El uso de un cliente de la versión 1.5 y un cliente de la versión 1.6 hacia el mismo repositorio puede crear este tipo de problema. (Me acabo de morder)

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

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

Esto puede ocurrir al menos en los repositorios 1.4, no estoy seguro de si el seguimiento de combinación introducido en 1.5 ayuda aquí.

Hasta hoy, desde hace al menos 3 meses, regularmente encontré cientos de conflictos de árboles al intentar fusionar una rama en el tronco (usando TortoiseSVN 1.11 ). Ya sea rebaseado o no, por cierto. He estado usando TortoiseSVN desde su v1, en 2004, y solía reintegrar ramas todo el tiempo. Algo debe haber sucedido recientemente, supongo.

Así que hoy realicé este experimento simple, y descubrí lo que estaba creando estos conflictos locos:

1. Bifurqué el maletero @ 393;
2. Modifiqué decenas de archivos al azar, además de crear nuevos;
3. Me comprometí Ahora @ 395 (un colega bifurcó a las 394 para realizar sus propias cosas).
4. Luego traté de reintegrar la rama nuevamente en el tronco, solo prueba; siguiendo la recomendación de TortoiseSVN en el asistente: "para combinar todas las revisiones (reintegrar), deje esa casilla vacía". Para lograr esto, hice clic derecho en la carpeta de troncales, y elegí "TortoiseSVN> Merge, from / path / to / branch", y dejé el rango de revoluciones vacío , como se indica en el diálogo.

Discusión: (ver archivo adjunto)

todas las revisiones ... de que? ¡Poco sabía que el cliente debía haber estado refiriéndose a " todas las revisiones del objetivo! (Tronco)", ya que, en el proceso de reintegración de esa rama, ¡vi la mención "Fusión de revisiones 1-CABEZA"! DIOS MIO. Pobre diablo, te estás muriendo aquí. Esa rama nació @ 393, ¿no puedes leer su certificado de nacimiento, por el amor de Dios?

Resolución:

1. Contrariamente a lo que aconseja el asistente, especifique un rango que cubra TODAS las revisiones de ... ¡la vida de la sucursal! por lo tanto, 394-HEAD ;
2. ahora ejecute esa prueba de fusión nuevamente y obtenga un cigarro. ( )

Moraleja: No puedo entender por qué todavía no han solucionado ese error, porque es uno, lo siento. Debería tomarme el tiempo para informar esto con ellos.

Hoy también me encontré con este problema, aunque mi problema 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: había estado usando temporalmente un archivo en un ensamblaje de otro ensamblaje. He realizado muchos cambios y no quería dejar huérfano el historial de SVN, así que en mi rama había movido el archivo de la carpeta del otro ensamblado. SVN no rastrea esto, por lo que parece que el archivo se elimina y luego se vuelve a agregar. Esto termina causando un conflicto de árbol.

Resolví el problema moviendo el archivo hacia atrás, confirmando y luego fusionando mi rama. Luego moví el archivo de regreso después. :) Eso pareció 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 nuevamente desde otro directorio raíz en la copia de trabajo que los tiene con:

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

Entonces hazlo

svn cleanup

y

svn add *

Es posible que reciba advertencias con la última, pero simplemente ignórelas y finalmente

svn ci .

Tuve este mismo problema y lo resolví volviendo a hacer la fusión con estas instrucciones . Básicamente, utiliza la "combinación de 2 URL" de SVN para actualizar trunkal estado actual de su rama, sin preocuparse demasiado por 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:

Suponga que tiene una troncal, desde la cual creó una rama de lanzamiento. Después de algunos cambios en el enlace troncal (en particular, la creación de un directorio "some-dir"), crea una rama de característica / arreglo que luego desea combinar también en la rama de lanzamiento (porque los cambios fueron lo suficientemente pequeños y la característica / arreglo es importante para el lanzamiento) .

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

Si luego intentas fusionar la rama de características / arreglos directamente en la rama de lanzamiento, obtendrás un conflicto de árbol (aunque el directorio ni siquiera existía en la rama de características / arreglos):

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

Por lo tanto, debe fusionar explícitamente las confirmaciones que se realizaron en el tronco antes de crear la rama de características / arreglos que creó el directorio "some-dir" antes de fusionar la rama de características / arreglos.

A menudo olvido que eso no es necesario en git.