En un entorno donde existe diversos desarrolladores de código fuente, el control de la concurrencia, así como disponer del histórico de modificaciones realizadas sobre los distintos archivos es muy importante. Con un sistema de control de versiones puedes revertir la situación de ciertos ficheros (incluso el proyecto completo) a estados anteriores, realizar comparativas entre las distintas versiones, localizar desde cuando se está produciendo un error, determinar el responsable del error, disponer de copias de seguridad de esos mismos archivos, etc.
Dos arquitecturas típicas son las distribuidas y las centralizadas. Los distribuidos son más habituales en grandes proyectos donde los desarrolladores se encuentran en múltiples localizaciones, se da la necesidad de replicar los repositorios y donde se producen múltiples ramas que terminarán (o no) fusionándose con la rama principal. Las centralizadas, por el contrario, son más habituales en pequeñas empresas y/o proyectos donde existe una mayor necesidad de trabajo en equipo.
Desde mi punto de vista, y pensando en la apuesta por el desarrollo de ERP sectorizado y vertical, el modelo de control de versiones centralizado me parece más eficaz, si bien con un servidor replicado que pueda entrar en uso inmediatamente tras una caída generalizada del sistema. Puesto que existe un equipo de trabajo concentrado en una misma ubicación física, no es un problema una caída de internet, el número de ramas puede ser controlado, el versionado es común, y el mantenimiento se puede realizar de forma centralizada.
Ver fuente
En otras situaciones podría ser más necesario el control de versiones distribuido: ubicación de los desarrolladores en todo el mundo, múltiples réplicas del proyecto, falta de recursos económicos para instalar un servidor y mantenerlo, etc.
En el mercado podemos encontrar múltiples sistemas de control de versiones, si bien nos centraremos en dos de los más conocidos, CVS y Subversion. Veamos algunas diferencias:
[bd_table]
| CVS | Subversion (SVN) | |
|---|---|---|
| Código Abierto | √ | √ |
| Licenciamiento | GNU GPL | Apache/BSD |
| Números de revisión | Por archivo | Por cada commit |
| Commits | Hasta ejecutarlo (problemas por tanto si se producen bloqueos) | Continuos y atómicos |
| Archivos binarios | Cada revisión se almacena por separado, ocupando mucho espacio | Los archivos, sean de texto o binarios, se almacenan en binario (y se compara en binario) |
| Directorios | No realiza seguimiento de cambios por directorio | Seguimiento y versionado de éstos |
| Renombrado archivos | No lo admite ni permite rastrear su historial de cambios una vez renombrado | Permite conservar el historial |
| Admite Metadatos | – | √ |
| Abrir ramas | Costosas proporcionalmente al número de archivos | Las ramas son continuas al ser directorios del sistema de archivos |
| Propagación cambios a repositorios padres | – | √ |
| Web | http://www.cvshome.org/ | http://subversion.apache.org/ |
[/bd_table]
Parece que CVS se ha quedado estancado en los últimos años. Particularmente prefiero Subversion, pues además, admite fuentes también en binario, por lo que parece una herramienta más idónea tanto por capacidad de almacenamiento como de comparación.
|
Recibe nuevos artículos mediante suscripción por e-mail, RSS o Feedly |
|
Excelente artículo sobre el control de versiones.
Los invito a leer nuestro artículo acerca de las principales excusas para no usar el control de versiones por parte de los desarrolladores, se sorprenderán.
Saludos cordiales!