Tag Archives: Svn

Subversion: the most pointless project ever

At least, that’s what he said…

When I say I hate CVS with a passion, I have to also say that if there any SVN users in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started, because the whole slogan for the Subversion for a while was “CVS done right” or something like that. And if you start with that kind of slogan, there is nowhere you can go. It’s like, there is no way to do CVS right.

Linus Torvalds

From his Git talk in Google last year, a really good one.

Git, ¿merece la pena?

Un sistema de control de versiones es una de las principales herramientas para cualquier programador, independientemente de si se esté trabajando en solitario o con un equipo de cientos de personas.

Desde hace un par de semanas estoy usando Git, un sistema de control de versiones distribuido desarrollado por Linus Tolvards (usado actualmente en el desarrollo del kernel). Git, está teniendo últimamente mucho hype. Pero las modas son muy peligrosas y siendo una herramienta tan fundamental, hay que evaluar a conciencia si realmente merece la pena usarla.

Comentando mi experiencia personal, tengo que decir que nunca me han gustado los SCMs. Comencé a usar subversion después de aprender a base de palos algunas de las causas de no usarlo. Aunque hasta hace poco no lo usaba plenamente, o todo lo bien que debería como para que empezase a ser una herramienta y no una carga. Pero a pesar de ello, todavía tenía auténtico pánico cada vez que se me pasaba por la mente las palabras branch o merge. Auténtico pánico.

Por suerte todo aquello es cosa del pasado (de hace 2 semanas :P). Lo que me animó a probar Git fue este estupendo post, merging by example, donde se muestra un ejemplo de uso en el que se van realizando diversos branches y merges de una forma lógica en un escenario típico del MundoReal™. Intenta hacer eso mismo con subversion (o si eres del pasado, con tu cvs) y me comentas (no pasarás del tercer merge sin conflictos).

Basta de contar mi vida y decir pamplinas, ¿qué ventajas aporta Git respecto a subversion? (digo subversion porque es el comúnmente usado, lo mismo se podría decir respecto a cvs pero con todavía más puntos).

  • Está de moda, y si lo usas molarás más, ¿no?. No hay mejor conversación para atraer a humanos del género opuesto que comenzar con un típico “¿sabes que uso git con una mano?”
  • Es distribuido. Esto tiene dos implicaciones muy importantes:
    • Independencia. Tú eres un repositorio, no necesitas ninguna información de ningún otro lado para realizar las operaciones. Es decir, no necesitas para nada red.
    • Mejor integración y comunicación en grupos de desarrollo grandes, pues cada desarrollador puede compartir cambios con el resto sin depender de un servidor central.
  • Rapidez, derivada principalmente por el anterior punto (y porque los que lo han implementado no deben de ser malos programadores, a decir verdad, según Linus la eficiencia fue uno de sus requisitos principales). Si para realizar una operación vas a necesitar acceder a la red (svn), quieras o no quieras vas a ser siempre mucho más ineficiente que alguien que no lo necesita (git)
  • Manejo más simple, intuitivo y eficiente de branches.
    • Con git puedes mergear varias ramas a la vez en una tercera (llamado merge octopus).

    • Mergear eficientemente ramas cuyo punto en común es un antiguo padre.
    • Y lo más importante (para mi :P), el scm conoce qué es un branch. Se acabo eso de tener diferentes directorios, uno por branch.
  • Git sigue y almacena contenido, no ficheros como lo hace svn. Esto tiene importantes repercusiones, una es (que podría considerarse negativa, para mi al menos lo es) que no soporta almacenar directorio vacíos (¡pues no tienen contenido! no hay nada que salvar) y otra es una detección transparente de movimiento de ficheros (renombrado, copias, movimientos, etc…).
  • Nuevo concepto, el index. El índice es un punto intermedio entre nuestros ficheros reales en el directorio de trabajo y el repositorio. Permite ser usado como un punto intermedio en el que almacenar (y preparar) nuestro cambios. En él podemos guardar nuestras modificaciones de forma temporal y recuperarlas posteriormente (por ejemplo después de cambiar de rama y arreglar lo que sea). O también podemos crear un commit personalizado creando un parche llegando a la granularidad de líneas de ficheros.

En resumen, es un cambio realmente significativo respecto al modelo tradicional (aunque podrías usar git con el mismo “workflow” que sigues en svn). De primeras es muy fácil de usar (algo que siendo un patan con estas herramientas, como lo es un servidor, se agradece), pero a su vez te permite profundizar y conseguir nuevos modelos de trabajo más productivos gracias a sus enormes posibilidades (el index es realmente útil). Es decir, tiene una curva de aprendizaje razonable pero que llega muchísimo más alto que la de svn (en cuanto a posibilidades), algún día llegaré a dominarlo pero mientras tanto me hace la vida más fácil.

Además puede ser usado teniendo repositorios de otro tipo como maestros (svn, por ejemplo gracias a git-svn), por lo que puedes seguir usando svn y localmente usar git sin “problemas” (tú trabajas con git, y git-svn se ocupa de manejar el subversion remoto, así estoy trabajando actualmente).

Por último mencionar algunas alternativas muy similares a git (es decir, que son distribuidos), los cuales desconozco completamente, pero que estoy casi seguro que son una mejor apuesta respecto al modelo svn/cvs. Los dos primeros escritos en python y el último en Haskell (¡con un par!):

Todo se podría resumir en una moraleja: Git, el sistema de control de versiones que no produce un incremento de deseo de participar en un suicidio colectivo.

Subversion en aplicaciones Java desde Ubuntu

Cualquiera que haya usado Java, tanto usuarios como desarrolladores, habrán tenido múltiples problemas debido al tipico problema del classpath y derivados. Es posiblemente uno de los (múltiples) principales problemas de Java. Y no será por soluciones adoptadas en otras ámbitos ampliamente usadas y aceptadas como válidas. Pero bueno, ese es otro debate.

Para poder interactuar con subversion desde aplicaciones Java necesitas la librería cliente JavaHL, ésta puede ser instalada fácilmente usando los paquetes de tu distro, en Ubuntu:

$ sudo aptitude install libsvn-java

Pero a pesar de esto, tus aplicaciones Java seguirán sin “encontrarla“, necesitas indicar en tu comando de ejecución de cientos de caracteres de tu aplicación el siguiente parámetro:

-Djava.library.path=/usr/lib/jni

Obviamente /usr/lib/jni es donde está la librería (el .so), quizá en otras distros no-ubuntu sea diferente.

En mi caso particular lo necesitaba para subclipse en Aptana, en cuyo caso hay que añadir esa opción al AptanaStudio.ini donde están los parámetros usados al arrancar Aptana.

Nuevos libros para la pila

Hace unas semanas, gracias a JavaHispano.org descubrí que Gonzalo de Zaragoza regalaba una serie de libros técnicos que se había leído ya. En aquellos días y con algo de suerte pude escoger el par de libros que más me interesaba, concretamente The complete reference Java Server Faces, y la guía sobre subversion.

Hoy he quedado con él, y después de conseguir llegar a tiempo e interpolar exitosamente su posición respecto al conjunto de gente que le apetece pasear en un día nublado, lluvioso y de -1ºC, que no es poca; ya los tengo en mi pila de libros por leer. Últimamente esta pila no para de crecer y nunca disminuye, quizá sea debido a intentar leer en paralelo varios libros, lo que produce un throughput muy bajo (debido, obviamente, a que solo tengo una unidad de procesamiento), tendré que optimizar este proceso en un futuro próximo.

Libros sobre JSF y SVN

Muchas gracias!