¿Cuándo es realmente necesaria la opción de reintegración?

Question

Si sincroniza siempre una rama de función antes de fusionarla de nuevo. ¿Por qué realmente tiene que usar la opción --reintegrate?

libro La Subversión dice:

Cuando la fusión de su rama de nuevo al tronco, sin embargo, la matemática subyacente es bastante diferente. Su rama de características ahora es una mezcolanza de cambios troncales duplicados y cambios de ramas privadas, por lo que no hay un rango contiguo simple de revisiones para copiar. Al especificar la opción --reintegrate, le está pidiendo a Subversion que replique cuidadosamente solo aquellos cambios exclusivos de su sucursal. (Y de hecho, lo hace comparando el árbol última tronco con la última rama del árbol: la diferencia resultante es exactamente sus cambios de la rama!)

Así que la opción --reintegrate sólo combina los cambios que son exclusivos de la función rama. Pero si siempre sincronizas antes de fusionar (que es una práctica recomendada, para tratar con cualquier conflicto en la rama de características), entonces los únicos cambios entre las ramas son los cambios que son exclusivos de la rama de características, ¿no? Y si Subversion intenta fusionar el código que ya está en la rama de destino, simplemente no hará nada, ¿verdad?

En a blog post, Mark Phippard escribe:

Si incluimos esas revisiones sincronizados, entonces fusionamos volver cambios que ya existen en el tronco. Esto produce conflictos innecesarios y confusos.

¿Hay algún ejemplo de cuándo dejar de reintegrar me da conflictos innecesarios?

Answer 1

Déjame explicar cuando --reintegrate es absolutamente necesario.

Considere el siguiente caso de uso.

1. que tienen proyecto p1 bajo P1/tronco. El proyecto tiene un archivo, readme.txt, con una línea "línea 1" <
2. Crear una nueva rama, p1/ramas/BR1
3. estadía en el maletero. Agregue la línea "línea2" al readme.txt y conéctela al tronco
4. Cambie a la rama p1/branches/br1. Actualiza a HEAD.
5. Combina desde el tronco a esta rama (para recoger los cambios del tronco).
6. Debe tener line1 y line2 en readme.txt
7. Commit fusionar el resultado de p1/branches/br1 rama
8. Cambiar al tronco. Actualiza a HEAD.
9. Combinar desde p1/branches/br1 to trunk.
   1. Verás line1, line2line2 y en readme.txt. Entonces, tienes "line2" dos veces, lo cual es incorrecto. SVN no muestra ningún conflicto. Por lo tanto, es muy peligroso porque la fusión se realizó sin errores y tiene la impresión de que todo está bien.

La solución aquí es que la combinación de la etapa 9 se debe hacer uso de la opción --reintegrate. La opción de reintegración le dice a SVN que compare br1 con el enlace troncal y aplique solo br1 cambios al enlace troncal. En este caso particular, no hemos hecho ningún cambio en br1. El resultado en trunk debe ser dos líneas "line1" y "line2".

Otra observación útil. La rama p1/branches/br1 ya no se debe usar para el desarrollo después del paso 9. Si desea continuar el desarrollo en sucursales, cree una nueva rama, por ejemplo, p1/branches/br2. Otra combinación de trunk a p1/branches/br1 causa muchos conflictos.

Answer 2

Creo que Mark significa que evita comparar dos archivos que se han modificado, uno para reintegrar desde la rama y su archivo correspondiente en el tronco, cuando ambos se han sincronizado (y no se han cambiado localmente en su rama respectiva).

Supongamos que tenemos trunk/a.c y branches/dev/a.c, con trunk/a.c modificado en algún momento y reintegrado en la rama más adelante con una combinación. Como señaló, es una buena práctica hacerlo antes de volver a poner todo en el baúl.

Así que el siguiente paso sería la fusión de nuevo a la troncal, donde a.c son "diferentes" en ambos lados, ya que han cambiado en ambas ubicaciones. Sin la opción habrá una comparación innecesaria, mientras que el --reintegrate hará que SVN vea que el cambio no fue solo local.

Answer 3

Es ’ s nunca es necesario utilizar --reintegrate — es ’ s simplemente un alias. Si usted tiene una copia de trabajo de trunk, entonces

svn merge --reintegrate url://feature-branch workingcopy

es lo mismo que

svn merge url://trunk url://feature-branch workingcopy

Usted puede usar lo que uno se siente más cómodo con.

Answer 4

Nunca es necesario usar --reintegrate; es una conveniencia.Si su combinación más reciente de trunk a feature-branch fusionó todos los cambios que ocurrieron en trunk desde que se ramificó a la revisión rev, entonces podría usar el siguiente comando.

svn merge url://trunk@rev url://feature-branch . 

Tenga en cuenta que este comando se ejecuta en la raíz de una copia actualizada al día de trabajo de trunk sin cambios pendientes que se ha comprometido.

Permítanme ampliar mi respuesta para responder más directamente a la pregunta "¿Hay algún ejemplo de cuándo dejar de reintegrar me da conflictos innecesarios?"

Esto es lo que significa el artículo por "Si incluimos esas revisiones sincronizadas, entonces fusionamos los cambios que ya existen en el tronco. Esto produce conflictos innecesarios y confusos".

Incluyendo las revisiones sincronizados sería el siguiente:

svn merge -r N:HEAD url://feature-branch . 

Dónde . es una copia de trabajo limpia del tronco y N es la revisión que feature-branch fue creado de trunk. Ese comando de fusión combina todos los cambios comprometidos con el feature-branch ya que fue ramificado, incluidos los cambios que se combinaron de trunk después de que se creó feature-branch. Eso significa que los cambios ya realizados en trunk se incluirán en la combinación anterior. Le diría a Subversion que aplique los cambios al trunk que en realidad se originó en trunk, lo que genera conflictos.