martes, 18 de octubre de 2011

RWJ. Control de versiones: Subversion (I)

Uno de los primeros conceptos que solemos abordar cuando incorporamos un programador sin experiencia a nuestro equipo de trabajo es el de sistema de control de versiones.

- ¿Alguna vez has hecho una práctica en equipo, cada uno programando un módulo?
- Si, una vez hicimos una aplicación web y mientras mi compañero escribía las páginas yo programaba el acceso a los datos.
- ¿Cómo compartíais los ficheros?
- Con una carpeta compartida de Windows.
- ¿Y podíais seguir trabajando cada uno en vuestra casa y al día siguiente juntar los cambios?
- No, teníamos que estar trabajando juntos con acceso a la red de Windows.
- ¿Guardábais versiones del código que generábais?

- Si, a última hora sacábamos un .zip con la fecha y la hora en el nombre del fichero.
- ¿No era un poco coñazo que si uno tocaba un fichero, al otro le dejase de compilar el proyecto? ¿Podías modificar los dos el fichero a la vez?
- No...

Los sistemas de control de versiones, a veces llamados también repositorios de código fuente - aunque un repositorio de código fuente no tiene por qué gestionar versiones- son herramientas diseñadas para evitar estos problemas (y algunos otros) de forma que facilitan:
  • Trabajar simultáneamente sobre un mismo proyecto a más de una persona.
  • Registrar qué cambios se han hecho en cada momento en el proyecto, quién los ha hecho o recuperar una versión antigua
  • Publicar los cambios que un integrante del equipo de proyecto ha hecho una vez están terminados, y no antes ( cuando puede que ni siquiera compile el proyecto).
  • Trabajar de manera offline , de manera que los cambios se pueden hacer fuera de la red y publicarlos después de un tiempo.
  • Etiquetar los diferentes entregables elaborados durante la duración del proyecto.
Los sistemas de control de versiones se clasifican en conectados y desconectados. Ejemplos de los primeros son CVS o SourceSafe. De los segundos: SVN, Git, Mercurial . La diferencia radica en que los entornos conectados requieren de una conexión continua al repositorio y éste controla, en cada momento, qué usuario está tocando qué ficheros; mientras que los entornos desconectados no requieren de conexión contínua. El principal inconveniente de estos últimos es que, como cada programador no tiene por qué saber si alguien más está editando los mismos ficheros, pueden aparecer modificaciones simultáneas de un mismo fichero de manera más habitual.

Los sistemas conectados han caído en desuso por su menor flexibilidad, y de los desconectados, el sistema con creces más usado es Subversion - SVN - .

Subversion se basa en la existencia de un repositorio centralizado de código en un servidor único, contra el que los diferentes desarrolladores interactúan mediante programas cliente como TortoiseSVN. La comunicación entre los clientes y el servidor se puede realizar mediante diferentes protocolos, siendo el más común http.

El repositorio SVN es un directorio en el servidor en el que se pueden subir ficheros y crear estructuras de directorios. Cada vez que se hace una subida o modificacion en el repositorio se aumenta el número de versión de los ficheros modificados y se almacena el login del usuario que realizó el cambio. Adicionalmente, se guarda un histórico de todas las versiones anteriores por las que ha pasado cada fichero.

Para recuperar una cierta versión del código el servidor busca las versiones de cada fichero con el mismo número de versión o con el mayor número posible por debajo. La última versión es la HEAD.

La dinámica de trabajo con SVN es simple. El programador hace un checkout de la versión HEAD del repositorio, cuyo resultado es la obtención de una working copy en su sistema de ficheros local. Este código puede ser modificado por el programador. Cuando el programador finaliza su trabajo hace un commit de sus ficheros de manera que sus modificaciones pasan a formar parte del repositorio, incrementando en una unidad la versión del código fuente.

Dado que el programador no tiene por qué estar trabajando solo, en cualquier momento puede hacer un update del código de manera que se actualiza su working copy con los nuevos cambios que otros programadores puedan haber realizado.

Si durante este tiempo otro programador ha modificado uno de nuestros ficheros, en el proceso de update aparecerá un conflict que habrá que resolver, unificando las modificaciones realizadas por nosotros mismos con las del otro programador. Si las modificaciones afectan a partes diferentes del fichero se suelen resolver de manera automática, pero en muchas ocasiones surge la necesidad de resolver los conflictor haciendo un merge de ambas versiones de los ficheros.



- Si, vale, muy bien, todo esto ya me lo sé que lo leí el otro día en un blog
- Pues enseguida te cuento cómo trabajar con esto, que es lo que no cuentan en todos los blogs.




2 comentarios:

  1. Yo recalcaría la parte de no resolver conflictos desechando los cambios de los demás. Por ejemplo.

    ResponderEliminar
  2. Eso se aprende con la experiencia xD

    ResponderEliminar