git
sudo apt-get install git-svn
Descargar: svn-migration-scripts.jar


java -jar svn-migration-scripts.jar authors <URL-SVN> > authors.txt
git svn clone --prefix="" --stdlayout --authors-file=authors.txt <URL-SVN>
cd <PROJECT>
java -Dfile.encoding=utf-8 -jar ../svn-migration-scripts.jar clean-git --force
git remote add origin <URL-GIT>
git push -u origin --all
git push --tags

vía

Anuncios

Estructura general

svn

  • En el trunk avanza el desarrollo de las nuevas versiones (1.0.0-SNAPSHOT).
  • En un momento dado se da por finalizado el desarrollo de dicha versión.
  • A partir de este estado se crea una rama para el mantenimiento de dicha versión (1.0.x).
  • En el trunk se actualiza la versión para que pueda comenzar la nueva iteración de desarrollo con nueva funcionalidad (1.1.0-SNAPSHOT).
  • En la rama se fija el número de versión final (1.0.0).
  • Una vez fijado el número de versión, se etiqueta (1.0.0) y esta versión será susceptible de ser instalada.
  • Una vez etiquetada la versión (1.0.0), en la rama de mantenimiento, se actualiza el número de versión para el desarrollo de los posibles correctivos (1.0.1-SNAPSHOT).
  • En cierto momento, se aplican cambios correctivos y se decide que la versión de mantenimiento está lista.
  • En ese momento se fija el nuevo número de versión (1.0.1).
  • A partir de este estado se etiqueta la versión (1.0.1).
  • Una vez etiquetada la versión (1.0.1) se actualiza el número de versión de desarrollo del mantenimiento (1.0.2-SNAPSHOT).
  • El proceso se repite tantas veces como sea necesario.

Lee el resto de esta entrada »

Subversion Logo
Tipos de merge:

  • sync o catch-up: un merge que introduce en la rama destino todos los cambios de la rama fuente que “todavía no tenemos” en la rama destino.
  • cherry-pick: un merge que introduce un o más cambios específicos de la rama fuente en la rama destino.
  • reintegrate: similar a un sync merge, pero pensada para ser utilizada en la otra dirección.

Asumamos un orden parcial entre branches, de tal modo que cada branch tiene (0 o más) Feature Banches que son menos estables que ella, y Release Branches que son más estables que ella, y ella se considera el padre de cada una de estas. Un merge se puede realizar entre una branch padre y uno de sus Feature o Release branches inmediatas, y en ninguna otra parte.

  • Un merge a una Feature Branch desde su padre normalmente es un catch-up.
  • Un merge desde una Feature Branch a su padre normalmente es un reintegrate.
  • Un merge a una Release Branch desde su padre normalmente es un cherry-pick.
  • Un merge desde una Release Branch a su padre podría ser un catch-up o un cherry-pick. (¿Funciona un catch-up correctamente y has hecho cherry-picks en la otra dirección? Puede que no.)

Subversive Logo
Inicialmente tenía conectados en Eclipse varios proyectos con un SVN utilizando el plugin Subclipse.

Debido a unos problemas en la creación de patches, tuve que cambiar a Subversive.

El problema viene porque una vez eliminado el plugin de Subclise y añadido el de Subversive, la única opción que aparece al pulsar botón derecho sobre un proyecto –> Team, es “Apply Patch…

Esto es debido a que Eclipse “recuerda” que el proyecto estaba conectado al SVN usando Subclipse (que ya no está disponible) y no me permite volver a conectarlo usando Subversive.

Para solucionarlo tenemos dos opciones.

La primera opción (des-instalar/re-instalar los plugins):

  1. Des-instala Subversive
  2. Re-instala Subclipse
  3. Verifica que los proyectos están conectados al SVN
  4. Botón derecho sobre el proyecto –> Team –> Disconect. Asegúrate de marcar “Do not delete the SVN meta-information (e.g. .svn subdirectories).
  5. Des-instala Subclipse
  6. Re-instala Subversive
  7. Botón derecho sobre el proyecto –> Team –> Share Proyect…

La segunda opción (si no quieres des-instalar/re-instalar):

  1. Crea un nuevo workspace vacío
  2. Abre Eclipse utilizando dicho workspace
  3. File –> Import –> General –> Existing Projects into Workspace
  4. Selecciona el proyecto del viejo workspace
  5. Botón derecho sobre el proyecto –> Team –> Share Proyect…

vía

Para que el tema de los merges del SVN funcione bien, se supone que la forma de trabajo sería la siguiente:

Creación de una nueva rama de código:

  • Todas las ramas (branchs) se deberían crear a partir de una rama principal (trunk)
  • A la hora de crear un branch se “aconseja” poner como comentario:
    Branch from trunk rev:28495
    donde Branch es el nombre de la rama y 28495 es la revisión de partida del trunk de la que se crea la rama

Mezcla de nuevos cambios del trunk al branch:

  • Actualiza tu copia de trabajo a la última versión del branch
  • Averigua el número de revisión del último merge (si todavía no se hizo ninguno, el número de revisión de creación, que, si sigues las indicaciones deberías tener en alguno de los comentarios)
  • Utiliza la herramienta de merge de subclipse para mezclar el trunk en tu copia de trabajo (Team -> Merge)
    • Las URL‘s que aparecen en “From” y en “To” deberían ser las del trunk
    • La revisión del “From” debería ser el número de revisión del último merge
    • La revisión del “To” debería ser “Head
    • Pulsa en el botón Merge y espera a que termine
    • En la consola se muestra un log del proceso realizado. Si aparece algún conflicto (marcado con una C roja, lo que hay que hacer es localizar dichos ficheros en el navegador de archivos, botón derecho y pulsar en Team -> Edit Conflicts, lo que abrirá un nuevo editor con dos paneles con una versión en cada lado. Se resolverán los conflictos (como se realiza normalmente al subir cambios al SVN) y, una vez corregidos, se vuelve al navegador de archivos, sobre el mismo y se pulsa Team -> Mark as Resolved.
  • Probar todo una vez mezclado 🙂
  • Subir los cambios de la mezcla a la rama y poner como comentario:
    Merged trunk changes 28495-29536 into branch X
    donde X es el nombre de la rama y 28495 y 29536 se refieren a los números de revisión inicial y final que se mezclaron

Pasar cambios de un branch al trunk

  • Actualiza tu copia de trabajo a la última versión del trunk
  • Averigua el número de revisión del último merge (si todavía no se hizo ninguno, el número de revisión de creación del branch, debería aparecer en los comentarios)
  • Utiliza la herramienta de merge de subclipse para mezclar el branch en tu copia de trabajo (Team -> Merge)
    • Las URL‘s que aparecen en “From” y en “To” deberían ser las del branch
    • La revisión del “From” debería ser el número de revisión del último merge
    • La revisión del “To” debería ser “Head
    • Pulsa en el botón Merge y espera a que termine
    • En la consola se muestra un log del proceso realizado. No debería aparecer ningún conflicto ya que se supone que el branch contiene lo último del trunk mas sus propios cambios.
  • Probar todo una vez mezclado 🙂
  • Subir los cambios de la mezcla al trunk y poner como comentario:
    Merged branch X changes 29536:29776 into the trunk
    donde X es el nombre de la rama y 29536 y 29776 se refieren a los números de revisión inicial y final que se mezclaron

Algunos enlaces de interés
Subversion Branching and Merging Techniques

A %d blogueros les gusta esto: