Para el éxito del desarrollo de un proyecto en un sistema de información o en general un Software cualquiera, sea elaborado de forma individual o con un equipo, se vuelve indispensable establecer un orden bajo un método de trabajo. Esto se logra mediante el uso de una herramienta que realice un control de versiones sobre el código fuente, como por ejemplo el Subversion (SVN), y en conjunto, un método para la enumeración de versiones como es utilizado en el Kernel de Linux.
Lo que vamos a explicar a continuación es únicamente la teoría del manejo optimo del código fuente, es importante destacas que no es la única forma de trabajar, existen varias en el mercado, cada quien escoge la que le conviene, pero esta es una de las más utilizadas en el mundo del desarrollo del software libre y/o código abierto. En un próximo post podemos hablar de los comandos necesarios para poner en practica esta metodología.
La metodología de trabajo que recomienda la gente de Subversion es bastante simple y flexible, solo debemos entender su esencia.
Todo un proyecto se debe ver como un árbol, como sabemos, el árbol esta compuesto por un tronco y muchas ramas, y en un determinado momento se le toma una foto para guardar un instante especifico en la historia.
Lo que se quiere decir del párrafo anterior, es que la estructura medular del proyecto es el tronco (trunk), y es la primera parte que da forma a todo el proceso. Posteriormente del mismo proyecto se derivan una serie de ramas (branches) para tratar un aspecto en especifico que no puede convivir con la rama principal (trunk), como son las actualizaciones y nuevas funcionalidades. Finalmente cuando el proyecto evolucionó para salir al publico, se le toma una foto (tag) que es una copia de la versión definitiva.
Como podemos observar en primera instancia, cada proyecto en el repositorio del SVN debe tener tres directorios principales, los cuales son:
proyecto/trunk/
proyecto/branches/
proyecto/tags/
Dentro de cada directorio se explica que debe contener, cual es su comportamiento y como evolucionan:
  1. trunk: En este directorio se aloja la estructura lineal del código fuente, en pocas palabras es el desarrollo principal. Es muy importante que siempre sea una versión funcional. Este es el punto de partida donde se sube la primera versión del código fuente en desarrollo, a partir de aquí se crean los branches. Nunca se deben subir los cambios realizados por el equipo directamente, el sentido correcto y que se debe respetar es que solo se puede hacer copy a los branches y a los tags, por ultimo un merge desde los branches.
  2. branches: En este directorio se utiliza cuando se crea una rama independiente del desarrollo principal, donde puede ser varias situaciones; una nueva funcionalidad del proyecto, mantenimiento, u integración. Se crean subdirectorios definiendo nombres a convenir según la circunstancias, sea el del equipo de trabajo, nueva funcionalidad, versiones, entre otros. La versión de trabajo es copiada desde el trunk. Cada programador que trabaja en un requerimiento en especifico debe tener su propia copia de trabajo y cuando suba los cambios se realizarán en su branch, sin afectar al desarrollo principal. Cuando esté listo para integrar sus cambios a la línea de trabajo principal, realizará una operación de merge.
  3. tag: Este es el directorio donde solamente se aloja las versiones de tipo release o en su defecto parches que serán dirigidas al publico, y su acceso es de solo “lectura”. Por cada versión liberada se crea un directorio bajo una enumeración de versión. Esta versión debe provenir de una copia del trunk. Los tags no evolucionan con el tiempo, solo el trunk.
Lo explicado anteriormente se representa en un diagrama lineal en el tiempo que nos muestra el ciclo de trabajo:
Representamos las tres líneas del desarrollo, cada cubo sobre las líneas representa una copia o directorio del proyecto, y las flechas indican el flujo y están acompañadas de una letra que representa las palabras copy y merge. Iniciamos con la primera copia que se sube en a hacia el trunk, luego realizamos una copia de a hacia el branch b, cuando termina el desarrollo, se hace un merge en el trunk como c y se publica en el tag la versión 1.0.0. El resto del diagrama mantiene la misma lógica.

Para mas información:
http://svnbook.red-bean.com/index.es.html