SVN y Eclipse: Hacer un merge

Publicado en Recursos el 19 de May, 2008 por Lek.

Se dice, y seguro que es verdad, que la forma de trabajar con SVN debe ser a base de branches y, una vez probados los diferentes cambios, pasarlo al trunk. Desde Eclipse, con el Subclipse, crear un nuevo branch es muy fácil, pero… ¿cómo se hace posteriormente el merge?

El día que tuve que hacerlo por primera vez seguí las instrucciones de aquí, la parte donde dice Merging Two Different Trees y que, traduciendo, resumiendo y ampliando, dice lo siguiente:

  1. Ponte en la copia local del Eclipse que apunta al trunk (muy importante)
  2. Pulsa botón derecho del ratón, selecciona Team → Merge
  3. En el campo “From” se indica la URL completa del trunk
  4. Selecciona la revisión en la que iniciaste el branch
  5. Desmarca el check del Use “From:” URL
  6. En el campo “To” se indica la URL completa del branch
  7. Selecciona la revisión del branch que quieres juntar (habitualmente será el HEAD)
  8. Pulsa “OK”
  9. Finalmente, comprueba que todo es correcto, corrige posibles problemas en el buildpath y realiza un commit

Este método es exactamente lo que se debe hacer también para volver a una versión anterior (ahora que está de moda, imaginemos el fallo de Debian), salvo el paso 5 ya que estamos con la misma URL. A pesar de que algunos lo odien, SVN es a buen seguro la herramienta de control de versiones más extendida y espero que lo anterior os sirva para vuestro día a día.

13 comentarios

  1. Hacer branches en svn es lo más doloroso del mundo. Escojo muerte.

    Menos mal que ya tenemos git :) (y git-svn para committear a repositorios legados)

    #  blaxter 19 de May, 2008

  2. Por dios blaxter eso de repositorios legados es la traducción más cutre que he oído de legacy (supongo que te refieres a esto), un poco de compasión por mis ojos.

    Pues yo nunca he usado svn, git, bazaar, … vamos que programo a pelo y me hago yo mismo mis versiones.

    #  Fran 20 de May, 2008

  3. ¿Doloroso? Hacerlos es muy sencillo, el problema para mí, como decía en el post, es luego juntarlos al trunk ;)

    Respecto a git, ¿qué mejoras tiene sobre SVN?

    #  Lek 20 de May, 2008

  4. @Fran, WTF? legacy es legados, ¿qué hay de malo en la traducción?. Cuando decía “a repositorios legados” estaba haciendo una ironía atribuyendo el adjetivo “legado” a todos los repositorios svn (si hasta ahora lo cutre era usar cvs, ahora svn se quedará también obsoleto).

    Dices que programas a “pelo”, ¿sin usar ningún CMS?, permiteme el atrevimiento, pero no creo entonces que te dediques profesionalmente a eso de escribir código, usualmente llamado programar. Y si lo haces, lo haces realmente mal.

    @Lek aparte de cambiar totalmente el modelo de CMS siendo éste uno distribuido, por nombrar las cosas que más me interesan: soporte nativo de branches, merges y parches, sigue contenido no ficheros, los merges los hace muchísimo mejor (si crees que svn trata bien los merges es que no lo has usado lo suficiente, en git puedes hacer branches de otros branches y así sucesivamente y luego hacer merges de n ramas a la vez y sin causar conflictos, intenta hacer esto en svn) y rapidez.

    #  Blaxter 21 de May, 2008

  5. s/CMS/VCS/g :P, estaba antes mirando cms’s y se me ha escapado la sigla

    #  Blaxter 21 de May, 2008

  6. Lo de que siga el contenido es una maravilla, porque en SVN cuando renombras te borra el fichero viejo y añade el nuevo (con lo que pierdes el log de commits).

    Y como decía, el problema de SVN para mí son los merges, no crear branches, branches con huevo y branches, huevo salchichas y branches, branches con branches (homenaje a los Monty Python, lo siento :P)…

    Bellz me ha mandado un correo también de Bazaar

    #  Lek 22 de May, 2008

  7. Blaxter pues actualmente no uso ningún VCS, ya que lo que programamos donde trabajo tampoco necesita de mucho código, realmente no desarrollamos productos complejos, obviamente si tuviera que realizar un mega proyecto con un equipo de N personas, entonces estaría claro que habría que usar un VCS.

    PD: Legacy sí es legado, pero realmente es una palabra poco usada y creo que en este contexto no refleja bien lo que se quiere decir, yo lo expresaría mejor como repositorios antiguos o heredados de SVN. (IMHO)

    #  Fran 22 de May, 2008

  8. un VCS es una herramienta fundamental en programación, todo lo que sea programar más de un día y que no sea prototipos debe estar en VCS. Aunque seas tú solo trabajando no es excusa para no usarlo (yo siempre trabajo solo por lo normal). Si realmente estás trabajando como programador, hazte un favor y comienza a usarlos, tu yo-del-futuro me lo agradecerá.

    pd: para mi decir legados es una palabra normal y corriente del español, supongo que sera una visión subjetiva.

    #  Blaxter 22 de May, 2008

  9. Yo también te recomendaría montar un VCS. Viene realmente bien aunque sólo sea para saber qué cambios se han hecho cada vez.

    #  Lek 22 de May, 2008

  10. Blaxter mi yo del futuro ya te lo agradece, porque hoy vamos a empezar a usar un SVN (llevabamos un tiempo queriendo poner uno por ver qué tal).

    PD: Te lo digo porque desde hace algún tiempo estoy traduciendo descripciones de paquetes de Debian y algún que otro programilla, y tengo la visión sensible de burradas que ponen algunos. ;)

    #  Fran 22 de May, 2008

  11. Gracias. Es justo la explicación que estaba buscando.
    Aunque me surge una pregunta:
    Al final del todo, cuando haces el commit, se supone que estás comiteando el trunk. Lo normal sería entonces crear un nuevo branch a partir de esta versión, no?
    Saludos.

    #  Raúl 25 de February, 2010

  12. Podrías crear un nuevo branch si es necesario, claro está. Se supone que los branches son para cambios que no se pueden/deben realizar directamente en la rama principal (soporte de versiones antiguas, por ejemplo, o para realizar desarrollos experimentales).

    #  Lek 25 de February, 2010

  13. @Raúl lo normal sería continuar con ese branch, pero en el próximo merge que hagas (en el futuro) será desde la versión que estás actualmente (pues acabas de realizar un merge) hasta esa_versión_del_futuro cuando haces el nuevo merge.

    En cualquier vcs decente, esto te lo hace transparentemente. En svn (=1.6), se supone que va guardando estos datos en el repositorio (y los merges ya no son un copy, sino un svn merge “real”), aunque esto último ya no lo he probado.

    #  blaxter 25 de February, 2010

Escribe un comentario