Subversion rebase?

Question

Me parece manera más fácil de fusionar ramas y menos conflictos:

Copiar el tronco a una nueva rama, fusionarla con la característica de la rama/s. Cuando haya terminado, combine la nueva rama con el tronco. Esta técnica es bastante similar a la modificación mercurial y git.

Solía ​​unir cualquier changs del tronco a una función de branche/s. Pero más tarde, cuando fusioné la rama de características con el tronco, algunas de las cosas del tronco se fusionaron nuevamente al tronco, lo que causó muchos conflictos. Hay una elección de fusión de reintegración, pero no pareció funcionar para mí.

¿Alguien hace similiar subversion rebasing? Empecé a hacer esto recientemente y no he visto ningún efecto secundario. ¿Esto causaría algún problema imprevisto?

Answer 1

estoy usando este enfoque:

Con rebase lo que tienes que tener cuidado de no tomar las revisiones sobre porcentualizada cuando combina de nuevo. En lo que respecta a la fusión, realice una selección al azar: seleccione solo las revisiones en la rama de características que implementan algo nuevo, no los conjuntos de cambios de rebase. Entonces debería funcionar bien. COMENTARIO: No recuerdo haber usado alguna vez la rama de reintegración. Creo que es solo para casos de uso muy simples.

En su nuevo enfoque, no queda claro en la descripción cómo maneja la rebase desde el troncal hasta sus ramas de características si es necesario. ¿Quieres deshabilitar por completo el rebasamiento? Como la bifurcación en svn es una operación económica, esta podría ser una opción también.

Answer 2

Ojalá tuviese un buen truco para decirle cómo lograr el rebasado en SVN, pero siempre he evitado la actualización manual de una rama con cambios en el tronco en SVN principalmente debido a las complicaciones que requieren selección manual de cereza que menciona jdehaan.

Lo que generalmente hago en cambio es seguir la práctica de fusionar los cambios de una rama al tronco, eliminar la rama y luego volver a crear la rama desde el tronco. Esto me permite actualizar/volver a establecer la base de mi rama de características, pero con el desafortunado efecto secundario de que los cambios anteriores de esa rama ahora forman parte del tronco. Por este motivo, solo sigo esta práctica cuando una rama de características se encuentra en un punto estable y utilizable, pero aún así deseo continuar trabajando en esa característica para poder completar un objetivo más grande.

Lo que yo preferiría es que al actualizar una rama al fusionar los cambios de troncales en una rama no se produzcan fusiones de reintegración posteriores de esa rama para obtener esas revisiones reordenadas durante el proceso. Debería ser posible hacerlo en base a las propiedades de información combinada, pero de acuerdo con lo que jdehaan declara y lo que he temido es que hacer esto todavía requiere una recolección selectiva.

Tenga en cuenta que la implementación adecuada de rebasado también debe poder tener en cuenta los ejemplos de la caja de escalera donde una rama se hace desde otra rama.

Actualización: De acuerdo con la documentación de Subversion parece que cuando se utiliza el --reintegrate option que Subversion debería poder reintegrarse adecuadamente el trabajo realizado en una rama de un modo que la mente las posibles fusiones de refresco que puede haber sido hecho para traer de base cambios en la rama. Por supuesto, esto es técnicamente un poco diferente al rebasado, pero creo que es lo suficientemente similar en el uso que podría denominarse como rebase.

Answer 3

En mi compañía utilizamos el enfoque siguiente:

1. para cada tarea NK $ X en el seguimiento de incidencias tenemos una rama ramas separadas/NK $ X
2. que empezar a trabajar en una tarea svn cp trunk branches/NK- $ X
3. Nunca realizamos cambios directamente en el enlace troncal. Para cada actualización programada UPDNK- $ X tenemos sucursales separadas/UPDNK- $ X. Lo creamos con svn cp trunk branches/UPDNK- $ X justo antes de la actualización.
4. cuando la tarea NK- $ X está programada para una actualización UPDNK- $ Y fusionamos branches/NK- $ X inot UPDNK- $ Y. Eso es cd UPDNK- $ Y; svn merge -r start: HEAD branches/NK- $ X
5. después de que UPDNK- $ Y esté listo, lo fusionamos en trunk. Es decir cd tronco; svn merge -r empezar: las ramas de cabeza/UPDNK- $ Y

Si sucede que la tarea NK $ X dura más de un ciclo de iteración, y por lo tanto necesita reformas, nunca, nunca, NUNCA fusione el tronco con NK- $ X. Tenemos una regla según la cual usted se compromete con su sucursal solo con las cosas que usted mismo escribió, lo cual hace que todo sea más fácil. En vez que hacemos:

cd NK-$X 
svn log 
//let L = the number of the last changeset to this branch changeset 
//let F = the number of the first changeset to this branch 
svn rm branches/NK-$X 
svn cp trunk branches/NK-$X 
svn up 
svn merge -r F:L branches/NK-$X@L 
svn ci -m 'refereshed' 

De esta manera, cada vez que nos fijamos en la lista de cambios de ramas/NK $ X que ver sólo cambia efectivamente realizado por el desarrollador.

Actualización: Dado que el flujo de trabajo anterior puede ser automatizado, he comenzado un proyecto en GitHub: svn rebase.

Answer 4

En términos generales, la rebase es el acto de incorporar cambios ascendentes en una rama de características, antes de fusionar la rama de características nuevamente en la rama ascendente.

En git, el proceso es aún más sofisticado, porque los cambios que se han realizado desde que se creó la bifurcación se quitan y almacenan temporalmente, se aplican los cambios ascendentes y luego se aplican los cambios almacenados. La conclusión aquí es fusionar el enlace troncal en una rama característica, no es una rebase en términos git, hay mucho más. El enfoque git tiene una serie de ventajas, pero no se puede implementar de forma muy clara en svn ya que todas las confirmaciones deben almacenarse en el servidor (svn no se distribuye), sin embargo, puede hacerse en svn.

Un 'rebase svn' (la forma GIT) podría ser algo como esto

1. svn cp trunk feature
2. se compromete a presentar & tronco
3. svn cp trunk feature-rebase
4. svn co feature-rebase
5. cd feature-rebase
6. svn merge feature
7. svn commit
8. svn rm feature
9. svn mv feature-rebase feature
10. (de nuevo WC función de rebase) svn switch feature

Entonces, finalmente, en una copia de trabajo del tronco, svn merge --reintegrate feature

Ves la diferencia de la simple fusionando el tronco a la rama de características? En este ejemplo, comienza con lo último de la línea de enlace ascendente, luego combina los cambios de la función en eso.

Imagine que algunas de las confirmaciones en el tronco podrían provenir de una fusión de otra rama de características en el tronco, por lo que no estoy abogando por comprometerse directamente con el tronco.