Algunas ideas de cómo usar subversion

Hace ya algunos años que comencé a usar SCM, primero fue CVS y ahora subversion. Existen otros muchos que algún día me gustaría probar, especialmente los distribuidos. Este tipo de herramientas se encargan de mejorar ciertas tareas que necesitamos realizar en distintos contextos. La finalidad de su uso puede ser variada. Personalmente uso subversion (svn) tanto para tener organizados mis script y archivos de configuración de los sistemas que uso, como para el desarrollo de proyectos software.

Dos de las ventajas que más destaco de la colaboración en proyectos de software libre es el intercambio de conocimiento y darse cuenta de que existen otras formas de hacer cosas que en muchos casos mejoran nuestras propias metodologías y resultados. Aunque subversion tiene un conjunto de operaciones cerradas, la forma de organizar nuestros repositorios es completamente abierta. Siempre que me surgía algún problema con los repositorios pensaba que algo no debía estar haciendo correctamente porque si proyectos de software libre en los que participan decenas de personas evolucionaban de forma fluida y constante, mis proyectos (que son mucho más pequeños) también debían hacerlo. Me resultaba difícil pensar que ellos también se tuvieran que enfrentar a los mismos problemas.

A continuación expongo algunas ideas que describen la forma en la que trabajo con los repositorios de subversion.

Definir nuestro repositorio con la siguiente estructura de directorios:

  • /trunk: Este directorio se caracterizará por ser uno de los directorios con mayor actividad. En él se almacenarán las últimas implementaciones. Parece lógico pensar que el estado del proyecto que contiene, es inestable. Sobre este directorio trabajarán aquellos desarrolladores que estén implementando nuevas funcionalidades y/o refactorizando algunas partes del proyecto.
  • /tags: En este directorio se almacenarán instantáneas del proyecto. Estas instantáneas relacionan el proyecto con un instante de tiempo. Al igual que sucede que las fotografías, estas instantáneas son necesarias para recordar ciertos hechos o sucesos. Algunos hechos que considero necesario recordar a lo largo de la vida de un proyecto software:
    • Las distintas versiones (release) que se van generando dependiendo de nuestra planificación (roadmap). Por ejemplo, /tags/1.0.0, /tags/2.1.0-beta o /tags/2.8.5
    • Presentaciones o demostraciones que se suelen realizar a directivos, clientes o usuarios finales que necesitan ver el proyecto en su último estado. Evidentemente ese último estado se ha concebido horas antes de la presentación y en raras ocasiones ha dado tiempo a realizar pruebas unitarias, y menos aun pruebas de sistemas o funcionales. Aunque veremos que esto también se puede mejorar con una arquitectura e infraestructura que nos permita modelar nuestra metodología y filosofía de trabajo en la que la integración continúa estará presente.
  • /branches: A diferencia de las etiquetas (tags), las ramas son instantáneas que evolucionan. Por lo tanto, en este directorio almacenaremos una instantánea que bien se ha podido obtener de la rama principal (trunk), de otra rama (branch) o de una etiqueta (tag). Algunas situaciones en las que considero necesario crear una rama:
    • Para almacenar las versiones que compartan la parte mayor de nuestro sistema de versionado. Por ejemplo, en el caso de estar usando un sistema de versionado compuesto por tres bloques (X.Y.Z), nos interesará crear una por cada par X.Y. De esta forma, dispondremos de una rama para mantener las versones de la forma X.Y. Supongamos que acabamos de obtener la primera versión de nuestro proyecto, y comenzamos a versionarlo por 0.1.0. Este justo instante deberemos generar la correspondiente etiqueta 0.1.0 a partir de la rama principal (trunk). A continuación generaremos la rama 0.1 partiendo de la etiqueta 0.1.0. En nuestro roadmap del proyecto estarán descritas las nuevas funcionalidades que se irán implementando en la rama principal y que originarán la versiones de la forma 0.2.x. Sin embargo, es muy probable que nuestra primera versión (0.1.0) tenga problemas que debamos resolver. En ese caso los problemas serán resueltos sobre la rama 0.1 y originarán nuevas versiones de la forma 0.1.1, 0.1.2, 0.1.3, etc.. Cada cambio que se realice sobre las ramas creadas para este fin, deberá ser reflejado si procede sobre la rama principal. Puede darse el caso de que el problema ya haya sido resuelto en la rama principal.
    • Las ramas para las versiones de la forma X.Y se crean para el propio mantenimiento de estas versiones dado que es aquí donde se han incorporado nuevas funcionalidades y éstas son candidatas a generar problemas. Por eso siempre se ha dicho que las versiones terminadas en 0 son menos estables.
    • A lo largo de la vida de un proyecto es muy probable que tengamos migrar a versiones más recientes de las librerías o frameworks de los que nuestro proyecto puede depender. Estas migraciones suelen ser delicadas porque pueden conllevar a una refactorización en nuestro código (patrones, métodos obsoletos, interfaces nuevas, etc). Para que estas migraciones no afecten directamente al desarrollo de nuestro proyecto es aconsejable crear una rama partiendo de la rama principal en que parte de los recursos de nuestro proyecto evaluen el impacto de tal migración. Cuando la migración se ha realizado satisfactoriamente los cambios realizados deben pasar a la rama principal. Ésta pudiera ser una de esas ramas que, por el motivo que las originó, no continúen evolucionado.
    • En algunos casos nos puede interesar que cada programador disponga de una rama propia de la forma user-dev para que puedan realizar sus pruebas y que éstas no interfieran con el resto de tareas. Adicionalmente, es una forma muy sencilla de tener una copia de seguridad y que sean ellos mismos quienes decidan cuando hacer los commits. Por regla general, suelo hacer commits asociados a una tarea (un commit, una tarea).

Si nuestro proyecto está formado por módulos perfectamente diferenciados quizás nos interese crear un nivel previo a la estructura antes descrita. Por ejemplo, podemos crear client-app/ y server-app/, y debajo de estos directorios crear nuestros directorios trunk, branches y tags.

7 thoughts on “Algunas ideas de cómo usar subversion

  1. Yo creo que no se debe trabajar directamente en la rama trunk. Es un error bastante típico, y que es una de las causas de mayores problemas en los RCS centralizados.

    Es mejor que cada vez que se vaya a realizar un cabio en el codigo principal, se haga una copia a otro sitio (branch), se trabaje ahi, y cuando esté terminado se haga un merge a la rama principal. Por supuesto usando svnmerge ( en SVN ), y no el mecanismo por defecto de subversion que es bastante malo e inútil ( ahora estan integrando svnmerge en SVN asi que pronto todo será mejor ).

    Trabajar directamente en trunk tiene consecuencias, y es que la mayoria de la gente tiene un montón de trabajo local, y solo hacen commits muy de vez en cuando.

  2. Hola Manuel:

    Totalmente de acuerdo contigo. Son pocas las ocasiones en la que se trabaja con la rama principal (trunk), prueba de ello es que cada programador tiene su propia rama en la que se implementa y posteriormente pasa los cambios a la rama principal.

    Sin embargo, en algunas ocasiones (proyectos pequeños y muy organizados) sea trabajado directamente con el trunk siguiendo algunas convenciones y reglas (1 ticket -> 1 commit).

    Y sobre el nuevo mecanismo para realizar el merge, yo también lo espero. Lo lei en http://subversion.tigris.org/merge-tracking/

    Un saludo

  3. Excelente artículo. Me va a servir de mucho para la gestión de mis proyectos, pero tengo una duda, estoy montando un sistema “casero” para gestionar mis proyectos con Trac y Subversion, en tú opinión qué es más recomendable ¿tener un único repositorio para varios proyectos o crear un repositorio por proyecto?

    Según he visto en la documentación de Trac permite admite ambas configuraciones, en concreto utilizando un scope si se tienen varios proyectos en un repositorio, por tanto me surge la duda si una opción tiene ventajas sobre otra. ¿Qué opinas?

    Gracias y saludos

  4. Hola Sergio:

    Como ya te he comentado esta mañana (tengo la suerte de trabajar contigo) con TRAC puedes gestionar múltiples proyectos sin embargo, echo en falta algún tipo de gestión de más alto nivel. Por ejemplo, un dashboard con información sobre la actividad de los proyectos, recursos, etc..

    Llevo usando TRAC desde hace varios años y estoy muy contento, sin embargo, otras opciones como RedMind (gracias Paco) me están haciendo plantearme el cambio.

    En cuanto a tu pregunta, mi recomendación, hasta que tengamos la versión 0.11 de TRAC, es que usen un único repositorio y que éste lo organices como te he comentado.

    Un saludo

  5. Me ha gustado mucho tu artículo( http://www.manuelrecena.com/blog/archives/70-Algunas-ideas-de-como-usar-subversion.html ), y ha sido el único en el que he empezado a ver un poco la luz a la hora de administrar mi repositorio software. Decirte que soy estudiante de Informática y que tengo frente a mi el problema de no tener totalmente claro que debe de ir en cada apartado (/trunk /tags /branches).
    Yo estoy haciendo un proyecto sobre una empresa de transportes y lo que hacía era organizarlo todo según el tipo de E.C. pero sin meterlo en ninguna de las carpetas anteriormente mencionadas. La verdad es que me vendría muy bien si pudiera pasarme algún ejemplo de repositorio para poder organizar el mio como ese.
    Voy a intentar dar ua idea de como tengo actualmente organizado mi repositorio:

    -ramas:

    -tags:

    -tronco:
    analisis_de_riesgos: LEEME.TXT
    AR_v.1.0.pdf

    pgcs: LEEME.TXT
    PGCS_v.1.0.pdf

    plan_inicial_de_proyecto: LEEME.TXT
    PI1_v.1.0.pdf
    PIP_v.1.0.pdf

    propuesta_inicial: LEEME.TXT
    propuesta_inicial.pdf

    sqap: LEEME.TXT
    SQAP_v1.0.pdf
    SQAP_v1.1.pdf

    Así es como actualmente lo tengo, a la espera de asegurarme como poder dejarlo bien.
    Espero que todo el que lea esto y sepa del tema pueda ayudarme.
    Muchas Gracias.

  6. Hola José María:

    Para poder orientarte necesitaría conocer algo más sobre el proyecto, sin embargo, hay algunas cosas que me llaman la atención:

    – No tiene demasiado sentido que tus archivos tengan la versión en el propio nombre cuando de eso se encarga el VCS.
    – Para la documentación quizás te resulte más interesante no tener esa estructura y con un “documentation/” sea suficiente.

    Si usas Skype, quizás resulte más fácil seguir abordando el problema que planteas.

    Un saludo

  7. Pingback: Pensando en Red » Blog Archive » Framework :: descargando el código de SVN

Leave a Reply

Your email address will not be published. Required fields are marked *