Hay ya muchos textos escritos sobre Subversion, pero hoy no hablaré de sus características, de lo que puede hacer ni de cómo lo hace. Hoy me centraré en qué es lo que le encontramos interesante para utilizarlo como herramienta en una empresa. En otras palabras: por qué lo utilizamos.

• Ha llamado un cliente. Dice que tiene un problema con la versión j29rc20. ¿Alguien sabe de dónde puedo conseguir esa versión para hacer unas pruebas?

• Uffff… j29rc20 significa “jueves 29, versión que estaba en el discoduro de Ricardo Cano a las 2:00”. ¡A saber dónde estará esa versión ya ahora!

Subversion guarda todas las versiones que pasan por sus manos. Además, permite dar un nombre (etiquetas, en nomenclatura SVN) a cualquiera de esas versiones. Así, si j29rc20 fuese una etiqueta SVN, obtener esa versión seria trivial.

• ¡Ostras! ¡He copiado esta versión encima de la antigua pensando que no tenía nada importante y me he cargado todo mi trabajo de la última semana!

En un repositorio SVN, la incorporación y mezcla de los cambios hechos por los diferentes usuarios (o incluso de copias de trabajo distintas de una misma persona) se realiza de manera automática, garantizando que nadie sobreescribe el trabajo de otro. Y si has borrado un archivo que no debías o has hecho cambios que no son correctos, siempre puedes recuperar cualquiera de las versiones anteriores que hay guardadas.

• ¿Cuando corregimos la alineación de las imágenes para IE6 lo hicimos mediante CSS o JS?

Subversion permite comparar fácilmente cualquier par de versiones de cualquier archivo. Si unimos a esto la posibilidad de explicar en los comentarios qué es lo que hemos modificado en cada versión, responder a esta pregunta es tan fácil cómo ojear la lista de comentarios e inspeccionar las diferencias de la versión relevante con la anterior. Además, nos vendrá de regalo la información sobre quién hizo ese cambio y cuándo.

• Queremos implementar una funcionalidad experimental que va a afectar la estabilidad del proyecto pero incluirla en la siguiente versión sólo si está ya suficientemente estable. Nos arriesgamos a ir haciendo los cambios o cómo lo hacemos?

En el mundo SVN la respuesta es única: mediante una rama. En cada rama que creemos podremos tener una evolución independiente del mismo código, de manera que no se interfieran entre ellas. Crea una rama nueva para implementar allí la funcionalidad experimental. Cuando el código esté maduro podrás integrar fácilmente los cambios en la rama principal antes de hacer la nueva versión. Si esa integración de cambios no llega a tiempo, la rama principal incorporará otros cambios no desestabilizadores pero nada de la rama experimental.

• Tenemos un directorio JS que es común a todos estos proyectos, pero ahora ha llegado una versión nueva del JS. ¿Tenemos que copiarlo a todos los proyectos uno por uno?

En SVN, no. Separa el directorio JS en un apartado del repositorio y vincúlalo al resto de proyectos. De esta manera, los cambios de cualquiera de los proyectos se trasladarán al JS común y de ahí a todos los demás proyectos. Modifica el JS común o la copia vinculada a cualquiera de los proyectos y todos los demás sitios se actualizarán por arte de magia. Todo lo que dijimos antes sobre la seguridad de no sobreescribir cambios de otros y las versiones se aplica aquí también, por supuesto.

Pero no todo es de color de rosa…

Subversion al fin y al cabo es sólo una herramienta. Que resulte beneficiosa o nociva depende del uso que se le dé. Hay algunos problemas muy comunes:

Subversion permite tener todos los archivos de un proyecto muy bien ordenados e indentificados. Pero no obliga a ello. De hecho, con etiquetas, ramas, vínculos y una estructura de directorios mal definida SVN puede llevarnos a un nuevo nivel de caos desconocido hasta la fecha.

Por otro lado, como cualquier otra tecnología, requiere un aprendizaje. Trabajar con una copia de trabajo en SVN es muy similar a trabajar con archivos normales. Demasiado parecido. Pero quienes acostumbren a copiar proyectos (o partes de ellos) de un directorio a otro se encontrarán con unas cuantas sorpresas desagradables al intentar sincronizar su trabajo con SVN, sin ir más lejos. También hay que aprender a crear archivos nuevos, borrarlos o incluyo renombrarlos o cambiarlos de sitio cuando residen en un proyecto SVN. Es igual de sencillo que hacer esas operaciones sobre archivos normales, pero hay que recordar que la manera concreta de hacerlo cambia.

Por último, para aprovechar los proyectos organizados que nos posibilita un repositorio de código lo mejor es tener una gestión organizada. Una gestión que establezca claramente las entregas, las versiones, los objetivos de cada una de ellas, las iteraciones de testeo y corrección de errores, etc…

Pero todo esto es ya material para otro post (sí: es una amenaza).