tortoise - svn fusionar la funcionalidad rota por conflictos de árbol
tortoise svn subir cambios (4)
svn: Intenta agregar un conflicto de árbol que ya existe
Subversion se queja porque después de que hiciste una fusión que generó un conflicto, hiciste la misma fusión nuevamente . SVN intentó agregar un conflicto pero notó que el conflicto ya fue creado por la operación de combinación anterior. Por lo que correctamente emite una advertencia.
Si realiza una operación de combinación y no está satisfecho con el resultado, antes de intentar otra cosa, primero debe revertir los cambios locales.
En cuanto al conflicto del árbol original: para entender por qué el comportamiento es diferente de los clientes anteriores y cómo resolver dichos conflictos, debe leer la sección sobre conflictos de árboles en el libro svn. El manual tortoiseSVN también tiene un buen tema sobre conflictos de árboles .
No sé cuándo el equipo de svn decidió infligir conflictos de árboles en nosotros, pero ha roto completamente la funcionalidad de combinación de svn.
Tengo una sucursal y quiero fusionar los últimos cambios del tronco en la sucursal. Ya he hecho una de tales combinaciones, 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 combinación (sin la --force ), solo creó el conflicto de árbol y no fusionó nada. Ahora solo reporta el mensaje de arriba.
Si hago svn status en la copia de trabajo de la rama, se muestran todos los archivos que tienen cambios que aún no se han fusionado en el tronco. Por supuesto, el propósito de mi sucursal es hacer estos cambios donde aún no están en el tronco.
¿En qué estaban pensando cuando hicieron esto?
No he encontrado ninguna información útil sobre las causas de los conflictos de árboles y cómo puedo continuar trabajando ahora que svn ha creado estas cosas.
¿Hay una manera de decirle a svn que se olvide de los conflictos de árboles y simplemente haga la fusión como solía hacerlo?
Estoy usando un cliente 1.6 y un servidor svn antiguo (probablemente 1.3.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 de árbol es confuso. Si svn hubiera seguido adelante y hecho la fusión, habría visto el problema al instante.
Los conflictos de árboles han introducido una nueva semántica de mensajes a la que llevará cierto tiempo acostumbrarse.
Gracias por el puntero a la documentación de la tortuga en conflictos de árboles. Es la única documentación que he visto que trata sobre el trabajo en las sucursales. Sin embargo, el ejemplo dado no explica por qué tuve conflictos de árbol en los archivos que había modificado en la rama. Los mensajes de conflicto de árboles van a tomar algún tiempo para acostumbrarse.
Parece que todo lo que haces en la mayoría de los casos es marcar los conflictos de árboles resueltos, y en estos casos parece que los conflictos de árboles son solo ruido.
Mark Phippard dice que una versión anterior del servidor no causará conflictos de árbol. El servidor solo necesita actualizarse si desea compatibilidad con el seguimiento de mezcla y su servidor es anterior a 1.5. Al parecer, el seguimiento de combinación es lo único que falta en los servidores svn más antiguos:
http://eclipse.open.collab.net/ds/viewMessage.do?dsForumId=62&dsMessageId=332448
Hola chicos, tuve exactamente el mismo problema, conflictos de árboles cuando intentaba hacer una fusión svn. Resulta que Laurynas fue absolutamente correcta. Ocurría porque el repositorio svn era una versión antigua. En el servidor entré en el directorio {repopath} / db / format y dentro del archivo de formato contenía "2".
Todo lo que hice fue hacer un
svnadmin upgrade {repopath}
que era bastante indolora.
Después de hacer eso, cuando intenté usar el seguimiento de fusión, ¡no tuve más conflictos de árboles! ¡Gracias por el consejo!
Supongo que está observando una mala interacción entre el cliente 1.6 y el servidor 1.3. La detección de conflictos de árbol es una nueva característica de 1.6. Además, el soporte de combinación se ha cambiado en 1.5 (y se ha hecho mucho más utilizable entonces).
Intenté actualizar el servidor y el formato de repo a 1.6, otra cosa que intentar es usar un cliente 1.5 (sin conflictos de árbol) o un cliente 1.4 (y sin combinación nueva).
Una vez más, todo esto es una conjetura y podría no ser realmente útil ...