Apache™ Bloodhound se gradua como proyecto de la ASF

Todo comenzó con ​una votación inicial en la lista de discusión ​bloodhound-dev@incubator.apache.org y el consecuente ​voto favorable de los ​miembros del IPMC . Hace unas pocas horas en ​un anuncio de Joachim Dreimann se dió a conocer que la junta directiva de la fundación ha decidido aceptar el sistema de gestión de incidencias ​Apache™ Bloodhound como un proyecto oficial. Gary Martin asumirá el rol de VP Apache Bloodhound .

Felicidades Gary . Ha sido un verdadero placer trabajar contigo durante más de un año . Felicidades también a todos los que han contribuido de una forma u otra a que este feliz acontecimiento suceda .

Todo esto ubica a Apache™ Bloodhound a la altura de ​Apache HTTP server , ​OpenOffice.org , ​Tomcat , ​Hadoop , ​Camel , ​CouchDB , ​Subversion ... y muchos , muchos otros sistemas líderes del mercado que ponen de manifiesto las buenas prácticas auspiciadas por la fundación durante sus ya más de diez años de existencia . A continuación les ofrezco más detalles .

Votaciones

Los resultados de las votaciones fueron los siguientes :

bloodhound-dev@…

Andrej Golcov (andrej)	+1	(non-binding)
Branko Čibej (brane, mentor/IPMC)	+1	binding
Gavin McDonald (gmcdonald, PPMC)	+1	binding
Gary Martin (gjm, PPMC)	+1	binding
Joachim Dreimann (jdreimann)	+1	(non-binding)
Jose Angel Franco Navarro	+1	(non-binding)
Jure Žitnik (jure)	+1	(non-binding)
Mark Poole (mpoole, PPMC)	+1	binding
Matevž Bradač (matevz)	+1	(non-binding)
Olemis Lang	+1	(non-binding)
Peter Koželj (peter)	+1	(non-binding)
Ryan Ollos (rjollos)	+1	(non-binding)

general@…

Branko Čibej	+1	binding
Chris Mattmann	+1	binding
Gavin McDonald	+1	binding
Greg Stein	+1	binding
Joachim Dreimann	+1	(non-binding)
Jure Žitnik	+1	(non-binding)
Matevž Bradač	+1	(non-binding)
Ryan Ollos	+1	(non-binding)

Propuesta de miembros para el PMC

Mat Booth	<​mbooth@apache.org>
Matevž Bradač	<​matevz@apache.org>
John Chambers	<​chambej@apache.org>
Branko Čibej	<​brane@apache.org>
Joachim Dreimann	<​jdreimann@apache.org>
Andrej Golcov	<​andrej@apache.org>
Peter Koželj	<​peter@apache.org>
Gary Martin	<​gjm@apache.org>
Gavin McDonald	<​gmcdonald@apache.org>
Ryan Ollos	<​rjollos@apache.org>
Mark Poole	<​mpoole@apache.org>
Greg Stein	<​gstein@apache.org>
Hyrum K. Wright	<​hwright@apache.org>
Jure Žitnik	<​jure@apache.org>

Listo para la versión 0.5.0

Aprovecho la ocasión para mencionar lo más relevante que ha ocurrido en este trimestre con relación al proyecto . En primerísimo lugar para la versión 0.5.0 se ha obtenido un nuevo diseño basado en ​Bootstrap que logra adaptarse a diferentes resoluciones de pantalla . Este es el primer paso con vistas a una orientación marcada hacia el mercado de dispositivos móviles (smartphones , tablets , ...) . En consecuencia se han incorporado ajustes y mejoras en los elementos de navegación del sitio , en la tipografía, las vistas de los tickets , administración y los formularios para adjuntar ficheros .

El explorador del repositorio, pendiente desde hace mucho tiempo, ya viene incorporado. Todos aquellos que ya tenían esta capacidad previamente instalada no tienen porqué preocuparse . Comparado con la versión que le ofrecíamos a nuestros clientes no hay cambios de ningún tipo .

También se han hecho grandes mejoras en el área de la ​búsqueda avanzada después de ser ​introducida en la versión 0.4.0. Ahora se resaltan las palabras clave de la búsqueda, y se mejora la calidad del algoritmo de indexación, entre muchas otras mejoras .

Sobre la infraestructura de la fundación ya hay dos demos en línea \o/. En ​https://bh-demo2.apache.org/ se puede ver la última versión estable (por el momento ​0.4.0) . En ​https://bh-demo1.apache.org se ha desplegado la versión más reciente en el repositorio (i.e. un nightly build basado en HEAD) . Aquí encontrará todo lo que está incluído en la versión 0.5.x y un poco más .

El voto del PPMC para liberar la versión 0.5.x es bastante favorable. Esto quiere decir que muy pronto todo esto estará listo para descarga desde algún servidor de la ASF . Solo que faltan ciertos tecnicismos y trámites burocráticos relacionados con la graduación , etc ... En fin que si Usted quisiera adelantarse, pues, todo esto está ya en el HEAD del ​repositorio. Las ​instrucciones de instalación son bastante precisas y le facilitarán el proceso.

Contribuciones hechas a Trac

Como parte de la implementación de la búsqueda avanzada a partir de ​una petición de un servidor se ha decidido generalizar y unificar el mecanismo de notificaciones de Trac . De esta forma en poco tiempo muy probablemente todas las interfaces de notificación de cambios e.g. ITicketChangeListener, IMilestoneChangeListener, ... serán descontinuadas en favor de una única interfaz IResourceChangeListener . Esto ya es un hecho en la copia que distribuye Apache™ Bloodhound . Los autores de los plugins no deben preocuparse en demasía (por el momento) puesto a que todavía se ofrece compatibilidad con el ramillete de interfaces existentes hasta el momento ... pero por favor , no creen más ninguna :P .

Otro aporte importante ha sido la separación de las instancias de la clase ComponentManager al ser enumerados los puntos de extensión . Sí , así mismo ... un rollo ... por lo que si está interesado en saber más le pido que lea ​este ticket . Esto será incorporado en ​Trac=1.0.2 . A lo mejor escriba alguna nota al respecto en los próximos días .

Perspectivas

Fundamentalmente a corto o mediano plazo hay dos o tres mejoras importantes . En primer lugar el soporte para múltiples productos ya es un hecho . En estos momentos estamos dando los toques finales a la primera versión que estará ya disponible para la ​versión 0.6.0 .

Hace pocos días con vistas a la graduación del proyecto y otros asuntos relacionados estuvimos analizando algunos retos y limitaciones que tiene el despliegue que utilizamos en la ASF . En lo que concierne al control de versiones ​un mensaje de Branko Čibej puso la última gota a un asunto que desde hace tiempo nos viene afectando de forma negativa : la integración del gestor de incidencias con los repositorios gestionados en la infraestructura d la ASF . La solución completa parece estar en torno al ​soporte remoto de repositorios svn y el manejo de hooks a través de ​pubsub . Esta última es una característica que será incluída en ​Subversion 1.8.x pero que desde ya está desplegada en producción en la infraestructura de la ASF . Esta configuración también facilitará otro ​enfoque de trabajo sugerido por Greg Stein , haciendo más énfasis en el repositorio .

Por otra parte hace unos minutos pude leer el ​anuncio de la versión 3.0.4 de ​trachacks:MasterTicketsPlugin y su ​futura integración con Apache™ Bloodhound .

Además de esto en la nevera tenemos otras sorpresas basadas en soluciones que ya hemos desplegado y ofrecido a varios clientes .

Conclusiones

Como siempre , espero que las mejoras sean de su agrado . No dude en comentar acerca de estas propuestas o sugerir mejoras . Todo es posible ... simelo piden .

@Wandisco propone Bloodhound, un fork de Trac

En  artículos anteriores les he hablado de  Trac , un sistema de administración de proyectos que me gusta mucho debido la calidad de su diseño. Soy el autor o contribuyo con  varios plugins. Me atrevería a decir que  Trac es el sistema de este tipo con más instalaciones funcionando en línea. Muchos projectos de software libre lo utilizan, e.g.  Pidgin,  PyAMF,  OForge ... muchos en realidad. También sucede que compañías como  Sourceforge también lo ofrecen en su paquete de  hosted apps .

Estado actual de la comunidad de Trac

Sin embargo en los últimos tiempos el desarrollo de la herramienta no ha sido lo suficientemente acelerado como algunos querrían. Hay algunas razones para haber llegado a este punto. En primer lugar ya  Edgewall (la compañía que gestó el proyecto) no es lo que solía ser unos años atrás. Además  el sitio de la comunidad necesita una actualización desde hace mucho tiempo ya. Todavía funciona con la versión 0.10, en un momento en que ya se está desarrollando la versión 0.13. Hay una buena distancia entre las dos, créanme. En mi opinión también sería muy conveniente que migraran el  repositorio actual basado en  Subversion para utilizar otro sistema distribuido, e.g.  Mercurial o  Git (me inclino por el primero pero todo parece indicar que ya hay una  propuesta de espejos para Git y  otra propuesta para Bitbucket).

Teniendo en cuenta mi experiencia personal también me inclino a pensar que los desarrolladores de los plugin puede que no tengan el apoyo necesario como para dedicarse a tiempo completo a realizar sus ideas. Por tal razón se dedican a hacer otras cosas mejor remuneradas.

Nuevos horizontes para Trac

Recientemente me ha llegado  una agradable noticia. Hay un fuerte interés en el desarrollo y mejora de  Trac. Todo comenzó meses atrás cuando un mensaje fue enviado a las listas  trac-users y  trac-dev. En estos momentos, gracias fundamentalmente a la compañía  Wandisco, esta petición a tomado vuelo y se concreta en una  propuesta llamada Bloodhound. La idea subyacente es integrar el desarrollo bajo la égida de la  ASF en el sistema  Apache Incubator. Esta fundación se destaca por dar vida a comunidades relacionadas con el código abierto. Entre las más destacadas se encuentran los proyectos  Subversion y el servidor  Apache httpd, ambos estrechamente relacionados con  Trac.

La idea que se maneja es clonar el código existente y comenzar una rama de desarrollo independiente , o sea que el proyecto anterior no muere. Por tales razones supongo que lograr una interoperabilidad entre ambos proyectos, al menos en un futuro cercano, es algo que beneficie a ambas partes. En el caso  plugins útiles y exitosos para ofrecer una solución llave en mano. del naciente Bloodhound la idea consiste también en empaquetar varios

Conclusiones

En pocas palabras , estoy muy contento al saber que todo esto está ocurriendo. Espero que la idea dé frutos y pueda salir a flote esta nueva herramienta. Habrá que seguir  la evolución de esta idea para ver qué resulta. Gracias a todos los que la han hecho posible.

Comparación de sistemas de control de versiones (a.k.a.VCS o SCM)

En esta breve entrada quería invitarles a que visiten el sitio http://versioncontrolblog.com , sobre todo si están tratando de decidir cuál sistema de control de versiones utilizarán. Allí es posible ver una tabla que compara las funcionalidades de los sistemas que se seleccionen teniendo en cuenta varios criterios como.

• Commits atómicos
• Soporte para seguir copias de ficheros y carpetas
• Duplicación remota del repositorio
• Control de acceso
• Posibilidad de trabajar en un único sub-directorio
• Interfaz web
• Disponibilidad de interfaces de usuario gráficas
• ... mucho más ...

Espero les sea útil el consejo ;o)

Tutorial: ¿Cómo migrar desde Subversion (SVN) hacia Mercurial con Hgsvn?

Después de sumarme al desarrollo del plugin de Trac para RPC (gracias a Odd Simon Simonsen ;o) y trabajar en unas mejoras, he decidido migrar mis proyectos anteriores desde Subversion hacia Mercurial. Aquí describiré una alternativa para realizarla. Por el momento no soy un experto, por lo que el análisis de las ventajas y puntos débiles de esta variante quedará pospuesto hasta que pruebe otras alternativas (si es que eso ocurre ...). Sin embargo, Usted puede formar parte de la búsqueda de la solución más adecuada y opinar u ofrecer sugerencias. Si desea saber acerca de cómo compartir código y colaborar utilizando repositorios de Mercurial, le sugiero que consulte un artículo previo sobre el uso de MQ con Bitbucket. Es así cómo se desarrolla el plugin que les mencioné anteriormente, utilizando su repositorio de parches.

_{Actualizado 23/04/2010 13:43:09 con hgpullsvn}

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 :
  • CVS
  • Subversion
  • Git
  • Darcs
  • Monotone
  • Bazaar
  • Arch
  • Mercurial
• 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.