subir - SVN cómo resolver nuevos conflictos de árbol cuando se agrega un archivo en dos ramas

svn eliminar archivos del repositorio

Question

Al fusionar un par de ramas (usando SVN 1.6.1) donde se ha agregado un archivo en ambas ramas (y luego trabajé en esas ramas separadas) estoy obteniendo uno de los nuevos conflictos de árbol:

      C foo.txt
  >   local obstruction, incoming add upon merge

Necesito los cambios de ambas ramas, pero el conflicto de árbol no me da los archivos habituales de trabajo, de izquierda a derecha y de derecha a izquierda, lo cual es comprensible debido a la naturaleza del conflicto. Hay bastantes de estos conflictos, y aquellos en los que se ha eliminado el mismo archivo en cada rama, pero son fáciles de resolver.

¿Cómo puedo resolver este problema? El libro redbean SVN (para 1.6) no cubre esta situación.

Answer 1

¿Qué pasa si los cambios entrantes son los que quieres? No puedo ejecutar svn resolve --accept theirs-full

svn resolve --accept base

Answer 2

Como se mencionó en una versión anterior (2009) del documento de diseño "Conflicto de árbol" :

Conflicto XFAIL de la combinación de agregar archivo versionado

Esta prueba realiza una fusión que aporta una adición de archivo sin historial en un archivo versionado existente .
Esto debería ser un conflicto de árbol en el archivo de la variedad '' local obstruction, incoming add upon merge ''. Se corrigieron las expectativas en r35341.

(Por cierto, esto también se llama "gemelos malvados" en ClearCase):
un archivo se crea dos veces (aquí "agregado" dos veces) en dos ramas diferentes, creando dos historias diferentes para dos elementos diferentes, pero con el mismo nombre.

La solución teórica es fusionar manualmente esos archivos (con una herramienta de diferencia externa) en la rama de destino '' B2 ''.

Si todavía está trabajando en la rama fuente, el escenario ideal sería eliminar ese archivo de la rama fuente B1 , fusionar de B2 a B1 para hacer que ese archivo sea visible en B1 (entonces trabajará en el mismo elemento) .
Si no es posible una fusión posterior porque las fusiones solo ocurren de B1 a B2 , entonces será necesaria una fusión manual para cada B1->B2 .

Answer 3

Encontré una publicación sugiriendo una solución para eso . Está a punto de ejecutarse:

svn resolve --accept working <YourPath>

que reclamará los archivos de la versión local como OK.
Puede ejecutarlo para un solo archivo o para catálogos de proyectos completos.

Answer 4

Me las ingenié para tratar de seguir el consejo de user619330 arriba. La situación era: (1): había agregado algunos archivos mientras trabajaba en mi rama inicial, branch1; (2) Creé una nueva rama, branch2 para seguir desarrollándola, ramificándola desde el tronco y luego fusionándome en mis cambios desde branch1 (3) Un compañero de trabajo había copiado mis mods desde branch1 a su propia rama, añadí otros mods, y luego se fusionó de nuevo al tronco; (4) Ahora quería fusionar los últimos cambios del tronco en mi rama de trabajo actual, branch2. Esto es con svn 1.6.17.

La fusión tenía conflictos de árbol con los nuevos archivos, y quería la nueva versión del tronco donde diferían, así que a partir de una copia limpia de branch2, hice un svn delete de los archivos en conflicto, comprometí estos cambios de branch2 (creando así un temporal versión de branch2 sin los archivos en cuestión), y luego se fusionó desde el tronco. Hice esto porque quería que el historial coincidiera con la versión de troncal para que no tuviese más problemas más adelante cuando intente fusionar de nuevo al tronco. La fusión funcionó bien, obtuve la versión troncal de los archivos, svn st muestra todo bien y luego conecté más conflictos de árbol mientras intentaba realizar los cambios, entre la eliminación que había hecho antes y la adición de la fusión. Hice una svn resolver los conflictos a favor de mi copia de trabajo (que ahora tenía la versión troncal de los archivos), y logré que se confirmara. Todo debería ser bueno, ¿verdad?

Bueno no. Una actualización de otra copia de branch2 dio como resultado la versión anterior de los archivos (fusión previa al troncal). Así que ahora tengo dos copias de trabajo diferentes de branch2, supuestamente actualizada a la misma versión, con dos versiones diferentes de los archivos, ¡y ambas insisten en que están completamente actualizadas! La comprobación de una copia limpia de branch2 dio como resultado la versión anterior (anterior al troncal) de los archivos. Los actualicé manualmente en la versión troncal y comprometí los cambios, volví a mi primera copia de trabajo (desde la cual había enviado los cambios troncales originalmente), intenté actualizarla y ahora obtuve un error de suma de comprobación en los archivos en cuestión. Sopla el directorio en cuestión, obtén una nueva versión a través de la actualización, y finalmente tengo lo que debería ser una buena versión de branch2 con los cambios del tronco. Espero. Desarrollador de avisos.