Hablando con un compañero (hola Xavi!) sobre SVN, he pensado que podría poner aquí algo sobre el tema. En las compañías, hoy en día, es muy frecuente usar SVN (subversion) como SCM (source-code management). Es así porque antes se usaba CVS, que daba muchos problemas, y el lema del producto es “CVS done right” (aunque según Linus no se puede “hacer CVS bien”). Bueno, y porque en ese momento era una buena herramienta, que funcionaba y además gratuita y software libre (sobretodo gratuita).

El problema es que los tiempos evolucionan. SVN cumplía su rol como SCM para un cierto tipo de estructura de trabajo, pero con nuevas metodologías más “ágiles”, con más desplazamiento de gente, teletrabajo, etc. se ha quedado obsoleto. Debido a que esa obsolescencia es de concepto no es fácil resolverla, ya que no se trata de añadir funcionalidad, sino de cambiar la filosofía del repositorio, pasar de solucionar el problema A a solucionar el problema B. Y eso no se hace sin reescribir todo el sistema.

Un ejemplo sobre las limitaciones de SVN es el sysadmin de mi empresa. Está harto de crear scripts y usar “3rd-party tools and addons” para poder administrar SVN sin problemas y sin dificultar nuestro uso. Pensaréis que son problemas que al usuario medio no le afectan, situaciones que un simple programador no suele ver o que un usuario con necesidades muy básicas no tendrá ya que apenas hará commit y update. Pero podemos buscar por internet una lista de quejas sobre SVN:
- Si cambias el nombre de un fichero, svn borra el fichero y añade el nuevo como un fichero diferente. Debido a esto, pierdes las referencias respecto a versiones anteriores ya que en ellas el fichero mantiene el nombre original que es borrado en cierto punto. Además svn no se lleva muy bien con eso de mover ficheros.
- No se pueden borrar revisiones antiguas del repositorio, la única forma es hacer un export, editarlo de importarlo de nuevo. La consecuencia es que siempre tendrás todo el código aunque no necesites revisiones muy antiguas y si por algún motivo has de borrar ficheros debido a un cambio de licencia, no puedes, están en tu repositorio.
- Los directorios .svn para gestionar la estructura están en el cliente. El borrado por error de un directorio de forma manual puede
crear serios problemas para el usuario, pudiendo necesitar un “checkout” entero.
- No hay distinción entre “branch” y “tag”, sólo su posición en el repositorio, lo que convierte al tag en una herramienta débil para su propósito ya que podría ser modificado mediante un commit.
- Las propiedades del repositorio se almacenan en el cliente, no en el servidor, con lo que si varían par algún proyecto, las has de editar manualmente en cada cliente.

Estos son algunos de los problemas. Personalmente yo añado a esta lista el trabajo con unidades remotas, algo que no gusta a SVN y evita poder usar los addons para Netbeans o Eclipse ya que acabas teniendo demasiados problemas con ellos debido a corrupción del directorio “.svn”. Como se ve, son situaciones muy comunes en las que cualquier programador puede encontrarse.

Actualmente SVN es unos de los SCM más extendidos, si no el que más, lo que hace que mucha gente por inercia lo use. Pero hay alternativas muy interesantes, que resuelven los problemas anteriores: los SCM descentralizados como GIT, Mercurial o Darcs. Entre las ventajas incluyen:
- Resolver los problemas de SVN
- Un 3-way merging muy eficiente que automatiza muchos merges
- Ser descentralizados, con lo que puedes trabajar de forma remota sin necesidad de tener un servidor accesible, haciendo commits, teniendo todo el código disponible (todas las revisiones anteriores) y realizando el merge cuando te encuentras con un compañero.

Ya hablaré de ellos con detalle otro día, pero os recomiendo mirarlos.