Linus Torvalds: Subversion rant 1
Aquí estoy otra vez, con GPU nueva; aunque no la que yo quería …
Esta vez voy a hablar de nuestro incombustible dictador benévolo, Linus Torvalds, y su nuevo flame encendido en una reciente conferencia en uno de los campus de Google acerca de los programas de control de versiones (SCM).
Durante los primeros diez años de mantenimiento del kernel, utilizamos literalmente tarballs y patches, que son un sistema de control de versiones muy superior a CVS.
Subversion solía anunciarse como que era CVS pero bien hecho. Con un eslogan así, no vas a ningún lado. No hay manera de hacer un “CVS” bien. Subversion es el proyecto más inútil de todos los tiempos.
Si te gusta utilizar CVS deberías estar en un sanatorio mental.
Por definición, cualquiera que no esté de acuerdo conmigo durante esta charla es estúpido.
— Linus making friends.
Para los que no conozcan a Linus en estado puro: es así la mayor parte del tiempo.
Veamos por qué oscuras razones una persona sensata suelta semejantes perlas delante de un centenar de ingenieros que utilizan Subversion como principal herramienta de gestión en su labor diaria.
Para empezar, Linus defiende las prácticas de branching y merging como conceptos clave que benefician el desarrollo de software. En este aspecto CVS, Subversion, SourceSafe y algún otro SCM son particularmente malos manejando muchas lineas de desarrollo paralelo simultáneamente, y cuando digo malos no quiero decir que no se pueda hacer, digo que las operaciones de branching y merging no son optimas en estos sistemas.
El branching facilita el desarrollo paralelo, hacer experimentos, crear checkpoints, ayuda a mantener el proyecto estable, básicamente ayuda a trabajar mejor. El branching es una operación sencilla en SVN, incluso en CVS, pero mezclar los cambios de dos ramas ya es otro tema: mezclar dos ramas lo suficientemente lejanas de su punto de bifurcación puede suponer en Subversion toda una mañana de trabajo viendo que código pasa y cual no. En CVS es mucho peor.
Otro de los problemas que comenta es el hecho de que el código y su historial esté ligado a un único punto de fallo: el servidor de versiones. Linus en cambio, aboga por un modelo completamente descentralizado similar a los sistemas P2P. Mercurial y GIT (desarrollado por Torvalds para gestionar el Kernel de Linux) son SCMs diseñados para trabajar de esta manera. No he utilizado estos sistemas pero se me antoja que la idea es muy buena para el modelo de desarrollo que siguen los proyectos open source.
Por lo que he podido entender (puedo esar equivocado ya que nunca he utilizado un SCM distribuido), en estos sisemas hay cientos de ramas paralelas a la linea de desarrollo que se esparcen viajando a lo largo de la red de pares y la carga se distribuye en “sumideros” que centralizan grupos afines de dichas ramas. Por ejemplo, a Linus como desarrollador del Kernel no le impora lo que están haciendo la gente del subsistema USB por lo que los envios a este módulo se reparten en su mayoría entre los desarrolladores involucrados en él, mientras que los envios al Kernel se distribuyen entre Linus y sus “hombres de confianza”, dejando el resto de la red libre de “ruido”.
Como nota curiosa/freak/MasterOfTheUniverse, Linus implementó este sistema (GIT) en un par de semanas de trabajo.
En Subversion y CVS toda la carga está centralizada en una única máquina, de forma que si 1000 personas estan trabajando contra el servidor al mismo tiempo (cosa habitual en un proyecto open source de envergadura), aunque lo hagan sobre módulos completamente aislados, estarán continuamente sobrecargando la máquina y pisándose unos a otros.
Diga lo que diga Linus, voy a seguir utilizando Subversion.
menéame
