Cualquier proyecto en el que intervengan varias personas usando los mismos ficheros, no tienen porque ser código fuente, requiere de un sistema de control de versiones que gestione unos repositorios donde se almacenarán las copias comunes de esos ficheros.
Una versión, revisión o edición de un fichero, es el estado en el que se encuentra dicho fichero en un momento dado de su desarrollo o modificación. Se llama control de versiones a la gestión de los diversos cambios que se realizan sobre los elementos de algún producto o una configuración del mismo. Los sistemas de control de versiones facilitan la administración de las distintas versiones de cada producto desarrollado, así como las posibles especializaciones realizadas (por ejemplo, para algún cliente específico).
Existen varios sistemas de control de versiones:
- Team foundation server de Microsoft
- CVS
- Source Safe de Microsoft
- Subversion ó SVN
Para este proyecto hemos decidido usar Subversion e integrarlo con Dynamics Nav para controlarlo dentro del mismo entorno de desarrollo al que estamos tan acostumbrados.
Subversion es un sistema de control de versiones con la política copiar-modificar-mezclar con gran proyección en la actualidad. Por ejemplo, SourceForge utiliza Subversion como control de versiones, también Google Code se basa en Subversion. Gran parte del éxito de Subversion es su agilidad cuando intervienen varias personas, debido a su política, y a su flexibilidad que no lo limita a desarrollos software: es posible almacenar planos, imágenes, libros…
A la hora de instalar Subversion hay que tener en cuenta de van a estar los repositorios y como vamos a acceder a ellos. Se puede acceder a los repositorios de Subversion a través de muchos métodos diferentes --en un disco local, o a través de varios protocolos de red. Una ubicación dentro del repositorio, sin embargo, es siempre una URL. La tabla describe cómo se corresponden diferentes esquemas de URL con los métodos de acceso disponibles. Métodos de acceso
| Esquema | Método de acceso |
|---|
| file:// | acceso directo al repositorio (en disco local) |
| http:// | Acceso a través del protocolo WebDAV a un servidor web Apache2 con Subversion incluido |
| https:// | Igual que http://, pero con cifrado SSL |
| svn:// | Acceso al servidor svnserve mediante el protocolo predeterminado |
| svn+ssh:// | Igual que svn://, pero a través de un túnel SSH |
En nuestro caso, hemos optado por acceso mediante el protocolo http. Para en lugar de instalar el paquete básico de Subversión hemos instalado Visual SVNServer que incluye el servidor web Apache.
No voy a meterme más en lo que es Subversion ya que se haría interminable el post, y además existe infinita documentación sobre este sistema de control de versiones.
Ya había cerrado el post, pero si quería comentar una cosa más. Subversion permite crear la estructura de repositorio que queramos, es cierto que se recomienda como mínimo tener las carpetas Trunk, Branches y Tags pero solo es una recomendación.
A la hora de decidir como queríamos gestionar el repositorio dudamos si esta recomendación, para la naturaleza de Dynamics Nav y como se afrontan los proyectos en un cliente Dynamics Nav sería adecuada, es más dudamos si no sería conveniente disponer de un repositorio para cada proyecto en lugar de una carpeta para cada proyecto dentro del mismo repositorio.
Al final, dado que nuestro interés radica en poder versionar los cambios en los objetos de Nav por proyectos, en que no necesitamos mantener una rama común, que podría nacer de los objetos estándar de Nav sin modificaciones, si no que nuestra rama común será tratada como un proyecto en sí y en que no necesitaremos mantener componentes externos (librerías de terceros por ejemplo) en los distintos proyectos hemos optado por la opción de tener un repositorio distinto para cada proyecto en lugar de todos los proyectos dentro del mismo repositorio.
Ahora si cierro el post ;)
