David Lay M

Una de las grandes diferencias que quiso hacer el equipo de SVN con CVS, fue facilitar la creación de ramas de código y habilitar la reincorporación (merge) de estas ramas en el tronco. Y claro que hicieron una gran diferencia, CVS, al mejorar los algoritmos de comparación y mezcla, pero en cuanto al proceso en sí, continuó siendo engorroso (aunque se podría decir que también mejoró un poco) Es por eso que necesito poner esto al aire, para que no se me olvide como hacerlo: El flujo de trabajo es el siguiente:

1. Crear la rama
2. Hacer cambios en la rama
3. Hacer cambios en el trunk (correcciones, mantención)
4. Traspasar cambios del trunk a la rama
   1. commit y update en rama y trunk (sincronizar ambos directorios a la misma revisión sin cambios pendientes)
   2. merge desde trunk HEAD hacia rama en la revisión de la última sincronización. (ver código más abajo)
   3. corregir cualquier conflicto producido
   4. commit de la rama
   5. update en el trunk
5. Repetir 2 a 4 hasta que el trabajo en la rama esté listo.
6. Traspasar los cambios de la rama hacia el trunk.
   1. commit y update en rama y trunk (sincronizar ambos directorios a la misma revisión sin cambios pendientes)
   2. merge desde rama HEAD hacia trunk en la revisión de la última sincronización. (ver código más abajo)
   3. corregir cualquier conflicto producido
   4. commit del trunl
   5. update en la rama

Como ven, el proceso sigue siendo engorroso al utilizar copias locales y es fácil equivocarse entre las revisiones. El siguiente ejemplo, es un merge del estilo 4.b (desde trunk hacia rama). El directorio de la rama es el directorio actual, y el trunk se encuentra en un directorio más abajo llamado “principal”. El último commit (en en trunk) se hizo en la revisión 3455(HEAD) y el último merge se hizo en la revisión 3452. Entre estas tres revisiones hubieron cambios tanto en el trunk como en la rama, pero solo vamos a traspasar los del trunk hacia la rama.

Bueno, siguiendo con mis experimentos en git-svn, tengo que decir que la implementación para windows frecuentemente corrompe los repositorios de svn al hacer el dcommit (enviar los cambios desde git hacia svn uno a uno según fueron hechos en git).

Afortunadamente estas corrupciones (hasta ahora) han sido sencillas de reparar gracias al comando

 

#svnadmin recover /home/svn/repository/your_repository_name 

Recuerden que luego del dcommit fallido, deben hacer un rebase ya que probablemente el dcommit tuvo éxito y fue el rebase el que falló ;)

Normalmente trabajo con svn en la oficina, debido a que es estable, es sencillo de usar, se integra muy bien con otras herramientas y funciona muy bien bajo windows.

Pero he estado probando git para hacer trabajos locales, experimientos y cosas locas y tener un mini control de versiones local antes de subir todo al trunk en svn. es la raja.

El único problema que tuve, fue que a git-svn no le gustó que el repositorio estubiera publicado en https. Al hacer el git svn fetch se caia, no bajaba nada y quedaba el repositorio corrupto. una mierda.

El arreglo: habilitar un servidor svn local apuntando hacia una ruta compartida en donde están los repositorios. (afortunadamente tengo acceso a ese servidor para configurar los accesos y todo eso).

En resumen:

     #habilitar share en servidor hacia repositorios

     \\servidor\repos\



     #iniciar servidor svn local

     $c/program files/Subversion/bin/svnserve -i \\servidor\repos



     #(en otra shell) iniciar repositorio mixto local

     $cd c/gitrepos

     $mkdir proyecto

     $cd proyecto

     $git svn init -s "svn://localhost/proyecto"

     $git svn fetch



     #iniciar programación! 

     $git checkout -b trabajo

El unico problema que veo, es que no es un proceso automático, y cada vez que quiera interactuar con svn voy a tener que iniciar el servidor local. A menos que configure svnserve como un servicio siempre apuntando a ese directorio, pero eso me parece mucho por ahora.

Más info (en inglés) sobre svn+git en:

http://www.jonmaddox.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/

http://andy.delcambre.com/2008/03/04/git-svn-workflow.html

http://blog.shinetech.com/?p=150

http://notes.jimlindley.com/2008/3/25/git-svn-that-works-for-me