svn - subir - ¿Por qué tengo conflictos de árboles en Subversion?
tortoise svn merge branch to trunk (11)
En mi experiencia, SVN crea un conflicto de árbol SIEMPRE borro una carpeta. No parece haber ninguna razón.
Soy el único que está trabajando en mi código -> eliminar un directorio -> cometer -> conflicto!
No puedo esperar para cambiar a Git .
Debería aclarar - yo uso Subclipse . ¡Ese es probablemente el problema! Una vez más, no puedo esperar para cambiar ...
Tenía una rama característica de mi troncal y estaba fusionando los cambios de mi troncal en mi sucursal 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 marcó como un "conflicto de árbol". ¿Hay alguna manera de evitar esto en el futuro?
No creo que estos estén siendo correctamente marcados.
Encontré la solución leyendo el enlace que dio Gary (y sugiero seguirlo).
Resumiendo para resolver el conflicto de árbol confirmando su directorio de trabajo con el cliente SVN 1.6.x puede usar:
svn resolve --accept working -R .
donde Es el directorio en conflicto.
ADVERTENCIA : "Confirmar su directorio de trabajo" significa que la estructura de su caja de arena será la que está comprometiendo, por lo que si, por ejemplo, eliminó algún archivo de su caja de arena, también se eliminarán del repositorio. Esto se aplica sólo al directorio en conflicto.
De esta manera, estamos sugiriendo que SVN resuelva el conflicto ( --resolve ), aceptando la copia de trabajo dentro de su caja de arena ( --accept working ), recursivamente ( -R ), comenzando desde el directorio actual ( . ).
En TortoiseSVN, al seleccionar "Resuelto" al hacer clic con el botón derecho, se resuelve este problema.
Esto puede ser causado por no usar la misma versión de clientes en 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. (Sólo me mordieron.)
Lo que sucede aquí es lo siguiente: crea un nuevo archivo en su troncal, luego lo fusiona en su rama. En la confirmación de fusión, este archivo también se creará en su rama.
Cuando fusionas tu rama nuevamente en el tronco, SVN intenta hacer lo mismo otra vez: ve que se creó un archivo en tu rama, e intenta crearlo en tu tronco en la confirmación de fusión, ¡pero ya existe! Esto crea un conflicto de árboles.
La forma de evitar esto, es hacer una fusión especial, una reintegración . Puedes 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
Sin embargo, cuando vuelves a unir tu rama al 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 --reintegrar, le está pidiendo a Subversion que replique cuidadosamente solo aquellos cambios exclusivos de su rama. (Y, de hecho, lo hace comparando el último árbol de troncales con el último árbol de ramas: ¡la diferencia resultante son exactamente los cambios de tu rama!)
Después de reintegrar una rama, es muy recomendable que la elimines, de lo contrario seguirás teniendo conflictos de trámite cuando te unas en la otra dirección: desde el tronco hasta tu rama. (Por exactamente el mismo motivo descrito anteriormente).
Hay una forma de evitar esto también, pero nunca lo probé. Puedes leerlo en este post: Reintegración de la rama de Subversion en v1.6
No sé si esto le está sucediendo, pero a veces elijo el directorio incorrecto para fusionar y recibo este error a pesar de que todos los archivos aparecen completamente bien.
Ejemplo:
Combinar / svn / Proyecto / ramas / alguna-rama / Fuentes a / svn / Proyecto / troncal ---> Conflicto de árbol
Fusionar / svn / Proyecto / ramas / alguna rama a / svn / Proyecto / troncal ---> OK
Esto podría ser un error estúpido, pero no siempre es obvio porque piensas que es algo más complicado.
Si encuentra conflictos de árbol que no tienen sentido porque no editó / eliminó / llegó a ninguna parte cerca del archivo, también es muy probable que haya un error en el comando de combinación.
Lo que puede suceder es que anteriormente ya fusionó un montón de los cambios que está incluyendo en su combinación actual. Por ejemplo, en el tronco, 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 previamente combinada aparece como suya 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 la fusión introducida en 1.5 ayuda aquí.
Subversion 1.6 agregó Conflictos de árbol 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 texto de ese archivo. Otra es cuando tiene una Subversión Renombrar un archivo que está editando ya que es una acción Agregar / Eliminar.
El blog Subversion de CollabNet tiene un gran artículo sobre Conflictos de árboles .
También encontré 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: había estado usando temporalmente un archivo en un conjunto de otro conjunto. Le hice muchos cambios y no quería dejar huérfano el historial de SVN, así que en mi sucursal había movido el archivo desde la carpeta del otro ensamblaje. SVN no hace un seguimiento de esto, por lo que 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 nuevamente, confirmando y luego fusionando mi rama. Luego volví a mover el archivo. :) Eso pareció hacer el truco.
Tuve este mismo problema, y lo resolví volviendo a hacer la fusión usando estas instrucciones . Básicamente, utiliza la "combinación 2-URL" de SVN para actualizar el enlace trunk al estado actual de su sucursal, sin preocuparse tanto por la historia y los conflictos de árbol. Me salvó de arreglar manualmente 114 conflictos de árboles.
No estoy seguro de si conserva la historia tan bien como a uno le gustaría, pero valió la pena en mi caso.
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, vuelva a copiarlos desde otro directorio raíz en la copia de trabajo que los tiene:
svn copy ROOT_DIR_NAME/SUB_DIR_NAME
Entonces hazlo
svn cleanup
y
svn add *
Puede obtener advertencias con la última, pero simplemente ignórelas y finalmente
svn ci .
Un escenario que a veces me encuentro:
Supongamos que tiene un tronco, desde el que creó una rama de lanzamiento. Después de algunos cambios en el troncal (en particular, la creación del directorio "some-dir"), creará también una rama de características / arreglos que luego desea combinar en la rama de lanzamientos (porque los cambios fueron lo suficientemente pequeños y la característica / arreglos es importante para la versión) .
trunk -- ... -- create "some-dir" -- ...
/ /-feature/fix branch
/- release branch
Si luego intenta fusionar la rama de características / arreglos directamente en la rama de lanzamiento, obtendrá 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 hicieron en el troncal antes de crear la rama de característica / arreglo que creó el directorio "some-dir" antes de fusionar la rama de característica / corrección.
A menudo olvido que como eso no es necesario en git.