Problema de fusión de subclipse: la ejecución en seco no coincide con los resultados de fusión

Estoy usando el complemento Subclipse 1.6x en Eclipse. Déjame explicar el escenario primero:

Supongamos que tengo el tronco de mi proyecto con las revisiones r1 a r100. En la revisión r100 creé una twig y comencé a cometer decir r101 a r105. En este punto, pensé en traer cualquier cambio del tronco para que mi twig se actualice.

Pero debido a un error de fusión, termino fusionando r80 desde el enlace troncal a mi sucursal y lo comprometí como revisión r106. Entonces revertiré mi cambio en r106 en la twig y haré otro commit r107 a esta twig.

Durante este time, ha habido confirmaciones, por ejemplo, r108 yr 109 en el tronco. Ahora, después de revertir mi commit erróneo en r106, introduzco correctamente todos los cambios de trunk hasta r109 en mi branch (por fusión) para que mi branch esté actualizada, y la envío a mi branch como r110.

Todo es bueno. Ahora decidí que no necesito la twig, así que permítanme unir todos los cambios en la twig (r110) de nuevo al tronco. Entonces, después de esta fusión, todo lo que debería ver son los cambios que hice en la twig (revisiones r 101 y posteriores en esa twig) ya que mi twig está actualizada con el enlace troncal.

Hago un equipo -> Combinar con desde url como tronco y como url como mi ruta de acceso. La revisión de From es la última revisión fusionada en trunk (r109) y la revisión To utilizada es la última en mi twig (r110). Probé una ejecución en seco y también creé una opción de file Diff unificado en la window Fusionar. Ambos se ven correctos y los únicos files actualizados son los que cambié en mi sucursal.

Ahora ejecuto el Merge y el resultado de fusión es diferente de Dry Run. Primero combina correctamente los files mostrados por Dry Run (que es lo que esperaba). Pero no se detiene allí. A continuación, intenta algo como esto: — Fusionando r80 a r110 (¿puede deberse a mi fusión incorrecta en la twig?)

y luego hace algo como: — Combinación inversa de r110 a r80.

El resultado final fue la fusión en todos mis cambios exactamente como el resultado de la ejecución en seco más muchas actualizaciones / cambios en otros files (debido a la segunda fusión y la fusión inversa, supongo).

¿Alguna idea de por qué esto podría estar sucediendo y cómo hacer que el resultado de la fusión sea el mismo / correcto que el resultado de la ejecución en seco? Incluso el file de diff unificado creado es correcto.

Gracias por leer la larga publicación.

El dialog de fusión Subclipse no se ha trabajado desde antes de Subversion 1.5 y la introducción del seguimiento de fusión. Le sugiero que instale el complemento CollabNet Merge Client que se incluye en el sitio de actualización de Subclipse y vea si obtiene los mismos resultados.

La opción Equipo> Fusionar debería mostrar un asistente si este cliente está instalado.

Ok, me di count de esto o al less lo resolví para mi caso. El problema se debía a que en mi sucursal erróneamente fusioné r80 del tronco y me comprometí como r106. Luego hice Team> Revert> last commit para revertir este merge-commit y lo compré como un nuevo commit r107.

Hay 2 problemas con esto. En primer lugar, esta no es la mejor manera de revertir una fusión de compromiso en SVN. Google para más detalles.

El segundo problema es cuando fusionas estos cambios (en múltiples commits) a trunk, SVN intentará aplicar cada commit uno por uno al trunk. Cuando desordero el r106 en la twig al fusionar el r80, SVN se confunde con el cambio debido a la ascendencia conflictiva de los files. Para evitar esto, y para decirle a SVN no te preocupes por el ancestro, solo combina las diferencias / cambios en mi twig con el tronco, marca la opción "Ignorar ancestro" en la window Fusionar. Esto me ocupó el problema.

También como una nota al margen, en la fusión de SVN, el resultado de Dry Run es equivalente a ejecutar Diff entre los files. Pero cuando realice la fusión, searchá en la ascendencia del file y traerá cada compromiso uno por uno para hacer la fusión. Por lo tanto, los resultados pueden no ser siempre los mismos. Hay más detalles sobre esto en la documentation de SVN.

Esto es lo que entendí de mi experiencia y estoy publicando esto aquí como respuesta, ya que no recibí ninguna otra respuesta a mi publicación. Por favor agregue cualquier comentario si no estoy del todo correcto.