Control de versiones

Escrito por moncada    1 Comentario

Cuando tenemos varios ordenadores tendemos a tener la información repartida por todos ellos, a veces con duplicados y aún peor, con versiones distintas en cada uno de ellos, de la misma información. Si esto lo extendemos al ámbito colaborativo para un proyecto en común que comenzamos a desarrollar entre amigos, o peor aún a nivel empresarial la cosa se complica.

Podemos optar por tener un lugar común (problemas de un sistema de ficheros en red, bloqueos de ficheros en uso…) en el que trabajar, en el que vamos dejando las cosas nuevas que vamos desarrollando para que todo el grupo pueda a su vez mejorarlas y actualizarlas. Como somos de naturaleza desordenada, al final cada uno tendrá diferentes versiones del mismo trabajo en nuestros ordenadores personales, y cuando nos vayamos a dar cuenta la versión real que sería la suma de los trabajos de cada uno de nosotros será muy difícil de conseguir o de obtener, cuanto menos saber lo que vale o lo que no vale, lo que funciona o lo que no.

Que es?

Un sistema de control de versiones es una herramienta que nos va a permitir marcar todos los pasos por los que pasa un proyecto, de forma que siempre se tenga la misma información y que esta sea actual.

Si lo utilizamos personalmente conseguimos tener un lugar centralizado de nuestro trabajo, las modificaciones que hemos efectuado del mismo a lo largo del tiempo, y poder recuperar la zona espacio/temporal en cualquier momento.

Si estamos en un grupo de trabajo conseguimos transmitir los cambios inmediatamente a todo el mundo. Separar nuestro proyecto en varias zonas según la madurez del trabajo creado (estable o desarrollo).

Pero no es oro todo lo que reluce, para que lo explicado en este mundo maravilloso funcione debemos de ser constantes y metódicos.

Tipos

Basándonos en lo anterior, los diferentes tipos vienen dados en la forma de trabajo de las personas a lo largo del tiempo y los problemas que se han encontrado en el uso de estos sistemas, bien por sistemas centralizados donde todo el mundo manda su trabajo y sincroniza, bien sistemas totalmente descentralizados. Metiéndonos más en materia veremos ya ejemplos concretos.

Centralizados

Los más conocidos son CVS y SubVersion, necesitan de una gestión avanzada de permisos y derechos de acceso en el servidor, esto da problemas en la colaboración. Si el servidor cae o se avería todo el mundo se queda parado, se necesitan medidas de seguridad mucho más importantes a nivel hardware para que la información sea estable y no se pierda. Problemas asociados en la unión de elementos y ramas de información distintas.

Descentralizados

Los más conocidos son Bazaar, Mercurial y Git, son muy fáciles de mantener, tan sólo hace falta disco y un servicio en el que colaborar con el servidor (http. sftp, ssh).  Todo el equipo tiene una copia clon del servidor, de manera que si el servidor cae se puede seguir trabajando sin problemas y no se pierde nada. Gracias a lo anterior podemos trabajar en el sistema de forma totalmente offline y establecer ramas de desarrollo personales y privadas.

Comenzamos

Después de toda esta variedad de sistemas vistos anteriormente (centralizados, descentralizados), queda claro que tenemos más ventajas con los sistemas descentralizados, ¿pero con cual nos quedamos?.

GIT

• Es distribuido, muy eficiente y muy muy muy veloz.
• El almacenamiento de este tipo de repositorios es bastante menor que en SubVersion (hasta 30 veces menos en el proyecto de Mozilla).
• La popularidad y el crecimiento de este sistema es mucho mayor que otros distribuidos.
• Lo utiliza el desarrollo del Kernel de Linux tras un cambio de licencia del que usaban anteriormente, 10 Mb de cambios al mes en forma de parches, 280 Mb de código fuente total y más de 6 millones de líneas de código.
• Posibilidad de utilizar varias ramas de desarrollo según la complejidad del proyecto.
• Y por supuesto es totalmente Open Source.

GIT vs SubVersion

A continuación voy a intentar plasmar las diferencias más notables entre GIT y SubVersion, y aún trabajando con ambos me quedo con GIT ya que lo considero más flexible en el trabajo que realizo a diario.

La primera diferencia que salta a la vista tras lo explicado anteriormente es la centralización o descentralización del repositorio, GIT no es totalmente descentralizado, puesto que siempre depende de un servidor donde almacenar la información, ni SubVersion es totalmente centralizado ya que también tenemos una copia local. Frente a ambas diferencias la verdadera razón de ser estaría en los commits, donde en GIT si son realmente locales y en SubVersion se hacen directamente en el servidor.

Debido a lo anterior en SubVersion cada commit tiene un número de versión consecutivo, mientras que en GIT puedo hacer muchos commits antes de aplicar el cambio global en el servidor.

En SubVersion es complicado dejar algún trabajo a medias, o símplemente crear una estructura con algún contenido no finito dentro de nuestra carpeta de trabajo. En GIT esto se hace mediante ramas y es bastante más eficiente que las de SubVersion.

Y si además te pica más la curiosidad, puedes ver un extenso razonamiento en detalle en la página de Scott Chacon.