SVN fusión automática para bifurcar en cheque en

Usamos una twig para nuestra próxima versión, y trunk para la próxima versión (más adelante).

Por ejemplo: v1.1 -> v1.2 -> trunk (donde v1.1 está en producción, v1.2 es la próxima versión y trunk se convertirá en v1.3 más cerca de la versión).

Mientras trabajamos en la próxima versión, nos registramos usando SVN (TortoiseSVN). El problema con esto es que todos los check ins se deben combinar manualmente en trunk si es un cambio que también será relevante para lanzamientos posteriores (la mayoría de los cambios en otras palabras).

El problema es que cuando los desarrolladores se estresan, tienden a olvidarse de fusionarse. La consecuencia de esto es que una corrección que se realiza en una twig puede necesitar ser arreglada más tarde porque el desarrollador olvidó fusionar la solución de la twig al tronco

¿Hay alguna forma de fusionar automáticamente el código en el enlace troncal cuando se realiza un check-in en la sucursal?

Sí, es posible, ¡y hay un proyecto de código abierto que lo hace!

echa un vistazo a https://github.com/liveperson/Auto-Merger

trabajamos constantemente con él y ahorra mucho time y ayuda a evitar todos los errores de fusión perdidos.

No, y yo desistiría estrictamente de ello. Hay tantos posibles efectos secundarios que te encontrarás con una fusión automática.

¿Cómo resolverías los conflictos? Cuanto más desarrollo significa más cambios en la twig y el tronco, significa más conflictos en la fusión. La fusión debe hacerse a mano.

¿Qué hay de las fusiones no deseadas? Hay cosas (como cambiar los numbers de versión, dependencies, etc.) que no desea fusionar. Con una fusión automática, tenía que invertir la combinación de las fusiones, lo que causa más confusión y trabajo.

Con la function de seguimiento de fusión de SVN 1.5, obtendrá buena información y verá si alguien no ha fusionado sus cambios de nuevo con el enlace troncal. Solo tienes que usarlo correctamente.

en realidad no se puede automatizar: incluso si no hay conflictos directos, la combinación podría dar como resultado un código que no funciona.

dos posibilidades para futuras mejoras, en order creciente de preference:

uno: comprometerse con trunk, tener a alguien designado para seleccionar las revisiones en la twig de lanzamiento

dos: cambiar a mercurial. srsly. es muy similar a svn, y es imposible olvidar una fusión, ya que fusionar la twig A en la twig B significa agregar en B todas las confirmaciones que están en A pero no en B

# alice edits some files and commits two revisions # into her repository, then pushes them into the master alice ~/wc/stable % hg ci alice ~/wc/stable % hg ci alice ~/wc/stable % hg push pushing to http://repo/stable searching for changes ... # bobby tries to push, but oops, his copy is stale bobby ~/wc/stable % hg ci bobby ~/wc/stable % hg ci bobby ~/wc/stable % hg ci bobby ~/wc/stable % hg push pushing to http://repo/stable searching for changes abort: push creates new remote heads! (did you forget to merge? use push -f to force) # bobby must augment his repository such that a push # to the master will leave the master with a single # head. this is achieved by pulling changes from # the master, which will cause *his* repository to have # two "head" revisions: bobby ~/wc/stable % hg pull searching for changes ... added 2 changesets with 4 changes to 4 files (+1 heads) (run 'hg heads' to see heads, 'hg merge' to merge) # he will now merge the heads to networkinguce them to a single # head. pushing that into the master will be ok (since # the result of such a push is a single head) bobby ~/wc/stable % hg merge bobby ~/wc/stable % hg ci bobby ~/wc/stable % hg push # ok! 

Se podría decir que esto es diferente de la fusión entre sucursales, pero en mercurial, cada copy de trabajo es efectivamente una twig, y ​​ambas situaciones se manejan con un solo set de commands:

 alice ~/wc/stable % hg ci alice ~/wc/stable % hg push alice ~/wc/stable % logout # alice went home without merging to trunk bobby ~/wc/stable % hg pull -u # alice's changeset is now his (only) head # he edits a file, commits it, and pushes bobby ~/wc/stable % hg ci bobby ~/wc/stable % hg push # his sole commit goes to the master # the push is ok since it results in a single head # bobby goes on to merge stable to trunk bobby ~/wc/stable % cd ../trunk bobby ~/wc/trunk % hg pull -u # pulls changes from trunk master bobby ~/wc/trunk % hg pull http://repo/stable # pulls all changesets that are in stable but # not in (this working copy of) trunk bobby ~/wc/trunk % hg merge bobby ~/wc/trunk % hg ci bobby ~/wc/trunk % hg push 

esta copy de trabajo anterior es importante, pero una copy obsoleta no te morderá: si la copy de trabajo de bobby estaba obsoleta WRT el maestro, el impulso fallaría y le pediría fusionar su combinación anterior con los nuevos cambios del maestro antes de volver a intentarlo.

Hmm, esto es muy similar a lo que hacemos aquí, pero no estoy al tanto de ninguna manera de hacer esto actualmente.

Normalmente, errores como este se detectan en nuestro process de revisión de código.

Me pregunto qué pasaría en el caso de un conflicto de fusión, y cuando eso ocurra, cómo se resolvería.

svnmerge.py hará un seguimiento de todas sus fusiones por usted.

Creo que esta es una gran idea y he querido implementar algo similar por un time. Mi idea hasta ahora es usar nuestro server de CI para hacer la fusión y luego ejecutar la construcción y las testings antes de verificar el resultado. Falla el trabajo de CI si la fusión no se puede hacer automáticamente (lo que luego debería notificar a alguien para que lo haga manualmente).

Con una cobertura de testing razonable, sospecho que los beneficios de automatizar esto superarán el problema ocasional causado por la fusión semánticamente incorrecta que no es detectada por las testings unitarias. Incluso eso probablemente podría eliminarse mediante una combinación de revisiones y fallando en el trabajo si las partes del código que se combinaron no están adecuadamente cubiertas por las testings.

Sí (además de la respuesta anterior, también recomiendo el proyecto svn auto fusion), vea este genial proyecto llamado automerger y ha fusionado con éxito cientos de twigs decenas de proyectos y cientos de miles de compromisos hasta el momento.

solo tiene que contarle sobre sus proyectos y de qué twig fusionarse para lo cual, por ejemplo, 1.0.0 -> 1.0.1 -> trunk -> 1.1.0 y como si fuera una magia cada compromiso con cualquier twig en entre se fusionará automáticamente hacia adelante. Te enviará notifications por correo electrónico para el éxito / error, actualizará la spreadsheet para informar, el file csv para informar, etc. e incluso creará jira tickets para fusiones fallidas para que los desarrolladores no se olviden de fusionar fusiones fallidas por sí mismos.

es un código abierto aquí es su enlace

svn automerger

Avíseme si tiene alguna pregunta o si tiene algún problema para iniciarla, ¡estaré encantado de ayudarle!