Estado inicial : Subversion
Subversion ha sido por mucho tiempo la opción más difundida para desarrollar proyectos de software libre. De hecho este es el sistema de control de versiones que fue ofrecido en primer lugar por Sourceforge, Google Code y casi todos los otros grandes patrocinadores del open source. Sin embargo el surgimiento primero de GitHub, luego de Bitbucket y otros sitios similares basados en Bazaar, han hecho que los sistemas distribuidos de control de versiones ganen una fuerza tremenda. En gran parte esto se debe a la inmensa gama de modelos de colaboración que son posibles cuando no se tiene un repositorio centralizado. De hecho, desde que comencé a utilizar SVN la sugerencia que nos hacia mi profesor, Alí, era que le echáramos un vistazo a SVK.
En este momento se gestó el proyecto FLiOOPS con una idea original de Kyrie (a.k.a. Luis Alberto Zarrabeitia) para concebir una implementación de la programación por contratos en Python. Lo que una vez fue una tarea de curso, con el tiempo fue creciendo y se incorporaron nuevas ideas. Entre todas ellas se destacó el módulo dutest, que se utilizó para escribir las pruebas de unidad. El aumento en la complejidad, implicó la existencia de varias ramas de desarrollo y otros elementos a los que Subversion no les da una solución. Por ejemplo acá les muestro la estructura actual del repositorio original :
/
java
trunk
branches
tags
py
trunk
branches
add_opts
mdl_inv
pep302
test_pycontract
guarded_synch
ochk_arch
pysimrec
tags
dutest
0_1_0
0_1_1
0_1_2
0_2_1
0_2_2
La buena noticia es que Sourceforge permite también el uso de (múltiples) repositorios de Mercurial y Git. Inicialmente esto hace posible tener un repositorio para cada lenguaje de programación, o para cada librería que se desarrolle en el marco del proyecto. Sin embargo hay que trasladar todas las versiones ya existentes hacia su nuevo destino.
Opciones para migrar
Después de buscar información e indagar un poco, encontré varias herramientas, pero parece que tres se distinguen del resto:
- HgSubversion es una
librería externa cuyo objetivo es lograr una integración completa con
Subversion.
- El comando convert
permite migrar repositorios de distintos tipos (incluso otros repositorios
hechos con Mercurial) hacia un repositorio de Mercurial. Como permite
filtrar y renombrar los contenidos que serán incorporados, también resulta
útil para filtrar repositorios Mercurial completos y obtener un
subconjunto de los cambios que resultan de interés. Entre los tipos de
herramientas soportadas se encuentran :
- Hgsvn es un projrcto que surgió a partir de la comunidad de desarollo de
Python para dar una respuesta a la
migración de los repositorios de la librería estándar. Varias de sus
características son:
- Los datos de las versiones se solicitan por lotes.
- El proceso es incremental, por lo que es posible interrumpirlo y resumirlo
posteriormente.
- Preserva los meta-datos (e.g. nombres y fechas de los cambios, registros
de copia y de cambio de nombres de ficheros).
- Crea marcas (a.k.a. tags) locales para cada versión en el repositorio
original.
- Preserva los nombres y las relaciones entre las ramas (a.k.a.
branches).
En todos los casos parece que el punto débil resulta ser la posibilidad de hacer commits en el repositorio SVN. Sin embargo, como ya les expliqué, este no era mi objetivo en este caso. Finalmente me decidí a utilizar Hgsvn.
Clonando el repositorio con Hgsvn
Hgsvn solo clona una rama a la vez. Considerando la estructura del
repositorio original, el primer paso es clonar el trunk. Para ello se ejecuta el comando hgimportsvn de la siguiente manera:
$ pwd
/home/olemis/repos/
$ mkdir flioops
$ cd flioops
$ hgimportsvn https://flioops.svn.sourceforge.net/svnroot/flioops/py/trunk > ./trunk.log
$ cd trunk && hgpullsvn >> ../trunk.log
En el ejemplo se redirecciona la salida hacia el fichero ./trunk.log para su posterior análisis. Les recomiendo observarlo, puesto a que conocerán los cambios que se van incorporando y los datos que se van recuperando del repositorio original. La lista puede ser larga.
En este caso se crea un repositorio dentro de la carpeta trunk. En general el nombre se corresponde con el último tramo de la URL que se especifica como parámetro. Podemos comprobar que todo está en orden después de observar el log del nuevo repositorio.
$ pwd
/home/olemis/repos/flioops/trunk
$ hg log | more
changeset: 49:39cfb58b31b6
branch: trunk
tag: tip
tag: svn.91
user: olemis
date: Wed Sep 17 10:34:32 2008 -0500
summary: [svn r91] - Bug fixed... The class PackageTestLoader loaded the tests defined in
changeset: 48:5595c9f190ca
branch: trunk
tag: svn.88
user: olemis
date: Thu Sep 11 14:38:56 2008 -0500
summary: [svn r88] Starting dutest release 0.2.1.
changeset: 47:ac470dd94852
branch: trunk
tag: svn.86
user: olemis
date: Thu Sep 11 12:10:25 2008 -0500
summary: [svn r86] - PackageTestLoader class added to oop.utils.dutest module. It loads
$ hg branches
trunk 49:39cfb58b31b6
$ hg tags -v | more
tip 49:39cfb58b31b6
svn.91 49:39cfb58b31b6 local
svn.88 48:5595c9f190ca local
svn.86 47:ac470dd94852 local
svn.83 46:0f8df4313c98 local
svn.82 45:287eef1166bf local
svn.80 44:7accc993aad9 local
svn.78 43:9ab9af3bbbfd local
svn.77 42:4678ec09ef71 local
$ hg log -r svn.88 -v
changeset: 48:5595c9f190ca
branch: trunk
tag: svn.88
user: olemis
date: Thu Sep 11 14:38:56 2008 -0500
files: utils/dutest.py
description:
[svn r88] Starting dutest release 0.2.1.
Como se puede observar solo obtenemos una sola rama llamada trunk. Su nombre se selecciona de manera análoga a partir de la URL. También se crea una marca local para cada revisión que se encuentra en el repositorio original. De esta forma es más fácil relacionar los cambios en un repositorio y otro. Por ejemplo la versión 88 en el repositorio central se corresponde con la versión 48 localmente, cuyo identificador global sería 5595c9f190ca. Además, si se nos olvidan estos detalles (de más está decir que yo me los sé de memoria :P ) pero conocemos la versión en el repositorio de Subversion, entonces es posible hacer referencia a su contra-parte en el repositorio de Mercurial utilizando el nombre (i.e. marca) svn.88.
Como se puede observar se mantiene el nombre del autor de los cambios y la fecha. Quizás le puedan quedar dudas ... pues ¡aclarémoslas!.
$ svn info
Path: .
URL: https://flioops.svn.sourceforge.net/svnroot/flioops/py/trunk
Repository Root: https://flioops.svn.sourceforge.net/svnroot/flioops
Repository UUID: 878b2ac5-cb47-0410-a52a-c42bf53788ce
Revision: 91
Node Kind: directory
Schedule: normal
Last Changed Author: olemis
Last Changed Rev: 91
Last Changed Date: 2008-09-17 10:34:32 -0500 (Wed, 17 Sep 2008)
Pues bien, en un mismo espacio coexisten ambos repositorios. Compare esta fecha con la que reporta Mercurial y verá que son idénticas. Después de satisfacer su curiosidad inicial, es hora entonces de clonar el resto de los cambios.
Clonando las ramas con Hgsvn
Como hemos visto antes, Hgsvn solo clona una rama a la vez. El proceso para recuperar los cambios restantes es análogo.
$ cd ..
$ pwd
/home/olemis/repos/flioops
$ hgimportsvn https://flioops.svn.sourceforge.net/svnroot/flioops/py/branches/add_opts > ./add_opts.log
$ cd add_opts && hgpullsvn >> ../add_opts.log && cd ..
$ hgimportsvn https://flioops.svn.sourceforge.net/svnroot/flioops/py/branches/mdl_inv > ./mdl_inv.log
$ cd mdl_inv && hgpullsvn >> ../mdl_inv.log && cd ..
$ hgimportsvn https://flioops.svn.sourceforge.net/svnroot/flioops/py/branches/pep302 > ./pep302.log
$ cd pep302 && hgpullsvn >> ../pep302.log && cd ..
$ hgimportsvn https://flioops.svn.sourceforge.net/svnroot/flioops/py/branches/test_pycontract > ./test_pycontract.log
$ cd test_pycontract && hgpullsvn >> ../test_pycontract.log && cd ..
$ hgimportsvn https://flioops.svn.sourceforge.net/svnroot/flioops/py/branches/guarded_synch > ./guarded_synch.log
$ cd guarded_synch && hgpullsvn >> ../guarded_synch.log && cd ..
$ hgimportsvn https://flioops.svn.sourceforge.net/svnroot/flioops/py/branches/ochk_arch > ./ochk_arch.log
$ cd ochk_arch && hgpullsvn >> ../ochk_arch.log && cd ..
$ hgimportsvn https://flioops.svn.sourceforge.net/svnroot/flioops/py/branches/pysimrec > ./pysimrec.log
$ cd pysimrec && hgpullsvn >> ../pysimrec.log && cd ..
$ ls
add_opts mdl_inv pep302 test_pycontract
guarded_synch ochk_arch pysimrec trunk
add_opts.log mdl_inv.log pep302.log test_pycontract.log
guarded_synch.log ochk_arch.log pysimrec.log trunk.log
Ahora todos esperamos efectos similares (i.e. marcas locales, una sola rama, fechas consistentes y dos repositorios en fraternal coexistencia).
$ cd add_opts
$ hg log | more
changeset: 36:660d2a6c5f05
branch: add_opts
tag: tip
tag: svn.54
user: olemis
date: Thu Aug 07 09:42:48 2008 -0500
summary: [svn r54] The error messages can be formatted now by specifying the templates
changeset: 35:0243dc200611
branch: add_opts
tag: svn.53
user: olemis
date: Thu Aug 07 09:36:52 2008 -0500
summary: [svn r53] The whole assertion checking infrastructure is prepared for
changeset: 34:84a28bf08590
branch: add_opts
tag: svn.52
user: olemis
date: Thu Aug 07 09:22:20 2008 -0500
summary: [svn r52] The function oop.utils.NormalizeException is prepared for assuming
$ svn info
Path: .
URL: https://flioops.svn.sourceforge.net/svnroot/flioops/py/branches/add_opts
Repository Root: https://flioops.svn.sourceforge.net/svnroot/flioops
Repository UUID: 878b2ac5-cb47-0410-a52a-c42bf53788ce
Revision: 54
Node Kind: directory
Schedule: normal
Last Changed Author: olemis
Last Changed Rev: 54
Last Changed Date: 2008-08-07 09:42:48 -0500 (Thu, 07 Aug 2008)
$ hg branches
add_opts 36:660d2a6c5f05
trunk 29:536184bf7e16 (inactive)
$ hg heads | grep changeset
changeset: 36:660d2a6c5f05
$ hg tags -v
tip 36:660d2a6c5f05
svn.54 36:660d2a6c5f05 local
svn.53 35:0243dc200611 local
svn.52 34:84a28bf08590 local
svn.50 33:7e5b743efd37 local
svn.49 32:901f61877293 local
svn.48 31:51e7d78f26d8 local
svn.47 30:336637e2a0f1 local
$ hg log -b trunk | grep changeset
changeset: 29:536184bf7e16
changeset: 28:ec176d410993
changeset: 27:d6ddd117926d
changeset: 26:1f89e8573172
changeset: 25:7b0847a67a80
changeset: 24:23571cc5686b
changeset: 23:cad71e6a4e34
changeset: 22:2d9e43109e87
changeset: 21:2a77c9c5e6ad
changeset: 20:c177d00b5a4e
changeset: 19:64eb1c7cdd91
changeset: 18:7c941992dbe5
changeset: 17:4dd286854034
changeset: 16:548c66a002c2
changeset: 15:7ad0521ce2b4
changeset: 14:f0087f96d466
changeset: 13:2540d610c198
changeset: 12:ee7e670e9b88
changeset: 11:8ba039171b0a
changeset: 10:af39f33a1776
changeset: 9:c95d926d676d
changeset: 8:28535deb9fc9
changeset: 7:1ddfa139931c
changeset: 6:84e23e55166e
changeset: 5:e1d36b91fb4a
changeset: 4:80257d1256a9
changeset: 3:6c81277c9392
changeset: 2:82714a5663d1
changeset: 1:89d45b024c67
changeset: 0:51750d40d056
$ cd ..\trunk
$ hg log -r 29:25 | grep changeset
changeset: 29:536184bf7e16
changeset: 28:ec176d410993
changeset: 27:d6ddd117926d
changeset: 26:1f89e8573172
changeset: 25:7b0847a67a80
Si bien hay varias semejanzas con respecto a los meta-datos, las diferencias son notables. Por lo visto hay menos revisiones y ... ¿dos ramas? ¿De dónde salió trunk si clonamos a add_opts? ¿Qué se puede deducir después de ejecutar los comandos anteriores? Primeramente, como las revisiones tienen el mismo identificador en ambos repositorios (trunk y add_opts) se puede deducir que se clonó el primer repositorio que teníamos localmente hasta la revisión 29:536184bf7e16. De ahi en adelante hgsvn detectó que en el repositorio SVN se había hecho una copia de los contenidos de la carpeta trunk y por tanto interpreta este hecho como la creación de una nueva rama y lo refleja localmente. En lo sucesivo solo se añaden las versiones en la rama add_opts. Es por esto que solo se crea una cabeza (a.k.a. head). La misma situación se repite para los otros repositorios.
Si Usted prefiere tener varias ramas en un solo repositorio (como yo ;o) solo resta unir todas las ramas.
$ pwd
/home/olemis/repos/flioops/trunk
$ find ../* -type d -print0 | xargs -0 -I repos hg pull repos
$ hg branches
ochk_arch 76:6ac33679d5c3
guarded_synch 75:386b8f866218
test_pycontract 73:d80a5ccc6153
mdl_inv 69:a9b380084029
pep302 62:00b7244f3642
add_opts 60:660d2a6c5f05
pysimrec 53:93e9562bfb41
trunk 49:39cfb58b31b6
$ hg heads | grep changeset
changeset: 76:6ac33679d5c3
changeset: 75:386b8f866218
changeset: 73:d80a5ccc6153
changeset: 69:a9b380084029
changeset: 62:00b7244f3642
changeset: 60:660d2a6c5f05
changeset: 53:93e9562bfb41
changeset: 49:39cfb58b31b6
Ya tenemos el repositorio con todas las de la ley. Lo único que es de resaltar es que desaparecen las marcas que indicaban los números de revisión SVN para las ramas, pues son locales a los repositorios clonados.
Conclusiones
Hgsvn solo clona una rama a la vez. Subversion no tiene implementada una noción de ramas, por lo tanto el comando hgimportsvn considera como nombre el último tramo de la URL especificada. La herramienta se destaca por mantener la mayor fidelidad posible con respecto al repositorio SVN original y recuperar la mayor cantidad posible de meta-datos para incorporarlos en la copia local hecha con Mercurial. Hgsvn analiza las operaciones realizadas en el repositorio SVN original e infiere las relaciones entre las ramas para reflejarlas en el clon que se crea localmente.
