2009-04-20 15 views
94

Al fusionar un par de ramas (usando SVN 1.6.1) donde se ha agregado un archivo en ambas ramas (y luego se trabajó en esas ramas separadas) I estoy poniendo uno de los nuevos conflictos de árboles:SVN cómo resolver nuevos conflictos de árbol cuando se agrega un archivo en dos ramas

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

necesito los cambios de ambas ramas, pero el conflicto de árbol no me da la .working habitual, & archivos .merge-derecha-izquierda .merge - - 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.

Respuesta

39

Como se mencionó en una versión anterior (2009) de la "Tree Conflict" design documento:

XFAIL conflicto de fusión de añadir más de fichero versionado

Esta prueba hace un merge, que trae una adición 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.

(Esto también se llama "gemelos malvados" en ClearCase por cierto):
se crea un archivo dos veces (en este caso "agregó" 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 usted todavía está trabajando en la rama de origen, el escenario ideal sería eliminar ese archivo de la rama fuente B1, fusionar vuelta de B2 a B1 con el fin de hacer que el archivo visible en B1 (a continuación, trabajar en el mismo elemento).
Si no se puede realizar una fusión porque las fusiones solo se producen desde B1 hasta B2, será necesaria una fusión manual para cada B1->B2.

+11

Pero, ¿cómo se hace una fusión manual sin los archivos .merge- *? – Quantum7

+2

El documento de diseño de "conflicto de árbol" es link podrido :( – whitey04

+2

Lo curioso es que incluso si ambos archivos agregados son _identicos_, siguen apareciendo como conflictivos. Esto realmente no debería marcarse como un conflicto. – SantiBailors

158

Encontré un post suggesting a solution for that. 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.

+2

Gracias, esto también resuelve: C foo.txt > local agregar, entrante agregar al actualizar – lazysoundsystem

+5

gracias también funcionó para mí, pero tuve que hacer esto: svn resolve --accept working FILENAME – ajacian81

+5

sí, necesitas un nombre de archivo. Acepta '.' (el directorio actual). También tuve que hacer esto recursivamente, así que: "svn resolve --accept working --recursive." resuelve todo en a favor de su copia de trabajo (¡peligroso! Puede que esté volando los cambios de otras personas cuando hace esto, como siempre al resolver conflictos) –

9

¿Qué sucede si los cambios entrantes son los que usted desea? Soy incapaz de ejecutar svn resolver --Acepte de ellos en toda la base --Acepte

SVN determinación

+4

Creo que he entendido mal la pregunta. 'base' es, de hecho, equivalente a 'su totalidad' cuando se usa 'svn resolve' pero no resuelve tu problema. Lo que hice, en cambio, fue dividirlo en dos partes: 1) Eliminar mi directorio conflictivo local (o archivo), 2) Fusionar. Esto debería ejecutarse sin conflicto, y como 'los cambios entrantes son los que quieres', no me interesarían los elementos eliminados –

1

simplemente me las arreglé para calzar a mí mismo bastante a fondo tratando de seguir el consejo de user619330 anteriormente.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 una svn eliminación de los archivos en conflicto, cometí estos cambios de branch2 (creando así una versión temporal de branch2 sin los archivos en cuestión), y luego hice mi fusión del 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.

Cuestiones relacionadas