svn fusión funcionalidad rota por conflictos de árbol

Question

No sé cuando el equipo svn decidió infligirnos conflictos de árbol pero ha roto por completo la funcionalidad de combinación de svn.

Tengo una sucursal y deseo unir los últimos cambios del tronco a la sucursal. Ya hice una fusión de este tipo, pero esta falla debido a un conflicto de árbol. Aquí está el comando:

$ svn --force merge -r 3185:3192 svn://chamar2/rx-services/SAMS . 
svn: Attempt to add tree conflict that already exists 

La primera vez que probé esta fusión (sin la --force) que sólo creó el conflicto de árbol y no se funden nada. Ahora solo informa el mensaje anterior.

Si hago svn status en la copia de trabajo de rama, muestra todos los archivos que tienen cambios que aún no se han fusionado al tronco. Por supuesto, el propósito de mi sucursal es hacer estos cambios donde todavía no están en el maletero.

¿Qué estaban pensando cuando hicieron esto?

No he encontrado ninguna información utilizable sobre las causas de conflictos de árbol y cómo puedo continuar trabajando ahora que svn ha creado estas cosas.

¿Hay alguna manera de decirle a svn que se olvide de los conflictos entre los árboles y simplemente haga la fusión como solía hacerlo?

Estoy usando un 1.6 cliente y un servidor svn anterior (probablemente 1.3.1).

Answer 1

El problema resultó ser que había elegido el directorio principal/como el origen de la fusión en lugar del directorio principal/troncal /. Fue un error del usuario, pero el mensaje de conflicto del árbol es confuso. Si svn hubiera seguido adelante y hubiera hecho la fusión, habría visto el problema al instante.

Los conflictos de árbol han introducido una nueva semántica de mensajes que tomará algún tiempo para acostumbrarse.

Gracias por el puntero a la documentación de la Tortuga en Conflictos de árbol. Es la única documentación que he visto que trata sobre trabajar en sucursales. El ejemplo dado no explica por qué tengo conflictos de árbol en los archivos que he modificado en la rama, sin embargo. A los mensajes de conflicto de árbol les tomará un tiempo acostumbrarse.

Parece que todo lo que hace en la mayoría de los casos es marcar los conflictos de árbol resueltos, y en estos casos parece que los conflictos de árbol son solo ruido.

Mark Phippard dice que una versión de servidor anterior no causará conflictos de árbol. El servidor solo necesita ser actualizado si desea soporte de seguimiento de fusión y su servidor es anterior a 1.5. Al parecer, el registro de fusiones es la única cosa que falta en servidores SVN de más edad:

http://eclipse.open.collab.net/ds/viewMessage.do?dsForumId=62&dsMessageId=332448 

Answer 2

Supongo que está observando una mala interacción entre el cliente 1.6 y el servidor 1.3. La detección de conflicto de árbol es una nueva característica de 1.6. Además, el soporte de fusión se ha cambiado a 1.5 (y ahora se puede usar mucho más).

Intentaría actualizar el servidor y el formato repo a 1.6, otra cosa que debe intentar es utilizar un cliente 1.5 (sin conflictos de árbol) o 1.4 (y ninguno combinar ninguno).

Una vez más, todo esto es una conjetura y podría no ser realmente útil ...

Answer 3

SVN: Intento de agregar conflicto de árbol que ya existe

Subversion se queja porque después de que hizo una fusión que generó un conflicto, entonces hizo la misma combinación nuevamente. SVN intentó agregar un conflicto pero notó que el conflicto ya había sido creado por la operación de fusión previa. Por lo tanto, emite correctamente una advertencia.

Si realiza una operación de fusión y no está satisfecho con el resultado, entonces antes de intentar otra cosa, primero debe revertir los cambios locales.

En cuanto al conflicto original del árbol: para comprender por qué el comportamiento es diferente de los clientes anteriores y cómo resolver dichos conflictos, debe leer el section on tree conflicts en el libro svn. El manual tortoiseSVN también tiene un buen topic on tree conflicts.

Answer 4

Hola chicos que tenía exactamente el mismo problema, los conflictos de árboles cuando yo estaba tratando de hacer un svn merge. Resulta que Laurynas tenía toda la razón. Se estaba produciendo porque el repositorio svn era una versión anterior. En el servidor ingresé al directorio {repopath} \ db \ format y dentro del archivo de formato contenía "2".

único que hice fue hacer una

svnadmin upgrade {repopath} 

que era bastante indoloro.

Después de hacer eso, cuando traté de usar el seguimiento de combinación, ¡no tuve más conflictos de árbol! ¡Gracias por el consejo!