La historia del control de versiones

12:01 18 Comments

La Gestión de Configuración de Software (Software Configuration Management, SCM, o Source Code Management para los hackers de verdad) existe ya desde hace una buena temporada y ha ido evolucionando lentamente desde los lejanos días casi prehistóricos en los que era casi una labor manual hasta la brillante actualidad de los sistemas DVCS (Distributed Version Control System).

Todos habéis usado al menos uno de los SCMs de la lista siguiente pero, ¿eres consciente de lo viejo que es el sistema que usas? ¿Conoces los grandes nombres? Vale, pues voy a intentar hacer una breve recopilación.

A grandes rasgos…


En el diagrama he colocado la mayoría de los principales nombres de la historia de los SCM. Sí, sí, ya sé que falta StarTeam, falta el nuevo sistema de IBM, ¿cómo se llama? RTC? Pero es que no me caben todos así que he dejado a los más feos fuera de la foto :P. En cualquier caso, escribe un comentario para hablar de tu sistema favorito (o el que más odias, o el que más has sufrido) tanto si me lo he dejado como si me he acordado de él...



Por si todavía te sientes bien usando uno de los “old irons” (hierracos :P), he añadido unas fotos debajo de cómo eran los teléfonos móviles de la época… para que no te quede más remedio que sentirte viejo y totalmente desactualizado :P.

Vamos, que si todavía estás usando CVS y piensas que “vale, está bien”, echa un vistazo justo debajo de “CVS” en el gráfico … ¿No te sientes como el protagonista de Wall Street, el dinero nunca duerme (Gordon Gecko/Michael Douglas) cogiendo el teléfono-ladrillo antes de salir de la cárcel? Pues eso. ;)

Nota: en los comentarios de mi post original en inglés algunos empezaron a protestar diciendo “eh, qué pasa, que porque un software haya empezado hace 20 años quiere decir que ya no sirve?”. Evidentemente no me refiero a eso. (Hay un comentario muy gracioso de un tío que usa el “grep” y protesta amargamente… para troncharse). El tema es que cuando el sistema evoluciona, pues no hay problema, pero hay sistemas en este dibujo de arriba que llevan muertos, sin evolución, con diseños anticuados, desde hace muchísimos años, y deformando la forma en la que los desarrolladores ven lo que es un control de versiones… A eso me refiero…

La prehistoria


Hubo un tiempo en el que las versiones se guardaban a mano. Vale, para muchos de vosotros ese tiempo no eran los 80 sino hace mucho menos, cuando en la universidad guardabais las prácticas con nombres como practica.zip, practica-version2.zip, practica-buena.zip, practica-buena-de-verdad.zip… Bueno, pues lo creáis o no, había un tiempo en el que la gente trabajaba sin SCM… era un tiempo sombrío y los programadores vivían en cuevas…

SCCS


Nota: añadido por petición de los lectores más nostálgicos!

En 1972 cuatro de los mejores hombres del ejército de los Estados Unidos que formaban un comando.... Espera! Para! Que me he equivocado de película...

En 1972 apareció SCCS y se quedó con el mejor nombre "Source Code Control System" así que a partir de ahí los demás han tenido que inventarse otros nombres porque ese ya estaba cogido... ;) Lo más interesante, además de ser uno de los primeros de verdad, es que su formato interno sigue usándose por TeamWare y BitKeeper. Más allá de eso... SCCS está ya fuera de combate, pero la historia no estaría completa sin él. (Gracias a los lectores por las notas!).

RCS


Y entonces llegó 1982 y RCS vio la luz (bueno, y naranjito, pero esa es otra historia). RCS no es un gran avance tecnológico pero todavía lo puedes encontrar en diferentes distribuciones de Unix. Es sencillo y va directo al grano.
Una buena característica era que los cambios de texto se almacenaban como deltas (muy importante teniendo en cuenta que los discos de la época no eran muy grandes). Los deltas todavía se usan actualmente en la mayoría de los SCMs.

Algunos inconvenientes y carencias que merece la pena mencionar:
  • Sólo soporta texto
  • No hay repositorio central. Cada fichero controlado tiene su propio repositorio en el formato de un fichero RCS, guardado cerca del propio fichero. Por ejemplo, el fichero RCS para /usr/project/foo.c será /usr/project/foo.c,v.
  • Para crear un workspace (espacio de trabajo) los programadores creaban links simbólicos a los directorios RCS. Ejemplo: symlink de /usr/home/John/RCS a /usr/project/RCS.
  • La nomenclatura de versiones y ramas es… hostil. Una versión podría llamarse 1.3 y una rama 1.3.1 y una versión en la rama 1.3.1.7.

    La época clásica


    En el mundo de los SCM, la época clásica fueron los 90.

    CVS


    Todo empezó con CVS (Concurrent Version System) en 1990. Era capaz de gestionar múltiples versiones desarrolladas de forma concurrente en diferentes máquinas y almacenadas en un servidor central. La era cliente-servidor estaba naciendo y los desarrolladores sacaron partido de ello.

    CVS era capaz de gestionar versiones de forma decente. Incluso soportaba ramas y merges (branching and merging) aunque no era muy bueno haciéndolo. Y esa es una de las razones por las que hay tantos programadores a los que les da miedo la letra “B” y la letra “M”… :P

    CVS no trazaba cambios en directorios o en nombres de ficheros (¡olvidad los refactors!) y necesitaba hacer bloqueos de todo el repositorio para muchas operaciones. CVS está totalmente desactualizado ahora pero… ¡funcionaba en los 90! Regla de oro: si estás usando CVS… no le des muchas vueltas… ¡¡cambia a otro sistema moderno!! Cualquiera (repito, cualquiera) será mejor. (Esto va dedicado a los equipos que evalúan 3 SCMs, encuentran pegas a todos y … ¡¡siguen usando un CVS o un VSS!!. En fin.).

    PVCS


    Polytron Version Control System (PVCS) vio la luz en 1985 y después fue cambiando de mano en mano a través de compras de empresas y fusiones: Polytron, Sage, Merant y finalmente Serena.
    Es un sistema viejo y desactualizado, inicialmente diseñado para evitar desarrollo concurrente usando bloqueos de ficheros, pero todavía mantenido por Serena Software.

    Clearcase


    En 1992 nació una de las mayores bestias de la historia del SCM. Clearcase estaba claramente adelantado a su tiempo y para muchos es todavía el SCM más potente jamás construido.
    Sin evolución clara, demasiado caro y demasiado complejo de administrar (en los viejos tiempos tenías que compilar un nuevo kernel de Unix para que funcionase la bestia!), el bueno de CC ya no es el tío guay de la ciudad, de hecho casi ya no se puede leer nada sobre él en la red. Pero, es todavía muy bueno con ramas y merges y tiene algunas características únicas, como las legendarias “vistas dinánicas”. Aunque potente, CC viene de una época en la que el espacio en disco era muy escaso y las redes eran LANs, sin preocupaciones por cosas como la latencia o trabajar tras un firewall.

    Atria, el desarrollador original de Clearcase, se fusionó con Pure (cuando lo dirigía Reed Hastings, ahora el jefe de Netflix), luego fue adquirido por Rational y finalmente por IBM. Y entonces el poderoso Clearcase dejó de evolucionar. Bueno, evolucionó hacia UCM a principios de 2000, que básicamente sirvió para quitarle todas las características buenas y dejar sólo las malas, junto con un precio demasiado caro. No fue muy buena idea.

    A pesar de todo Clearcase sigue siendo uno de los SCMs más usados por grandes empresas en todo el mundo, y según los analistas, uno de los líderes en cuanto a facturación.

    VSS


    Todos los sistemas de mi lista han tenido su momento y ventajas claras respecto a sus predecesores. Todos menos Visual Source Safe. VSS ha sido un sistema flojo desde el primer día, forzando a los desarrolladores a coordinar su trabajo mediante bloqueos, prohibiendo el desarrollo paralelo y creando una cultura de “miedo al merge”. Nota: vale, ya sé que se puede llegar a hacer un poco de desarrollo paralelo con VSS configurándolo para trabajar sin el modo de bloqueo… pero vamos, que creo que es menos doloroso dormir en una cama de clavos.

    Lento, lleno de fallos, limitado por todos los lados, VSS ha sido uno de los sistemas más utilizados por los desarrolladores en Windows en todo el mundo (¡ojo! Por los desarrolladores EN Windows, no los desarrolladores DE Windows, que en Microsoft la gente de los equipos punteros jamás utilizó esta aberración). VSS todavía está en uso, extendiendo el dolor y el miedo entre ingenuos programadores de buen corazón.
    Pero sí que hay una cosa en la que VSS estaba por delante de su tiempo: debería pertenecer a la categoría de “la oscura edad media del SCM” (ver debajo) en lugar de a la era clásica.
    VSS, eso sí, es totalmente gráfico y esa ha sido una de las principales razones de que se haya usado tanto (eso y que venía con Visual Studio ;) ).

    Perforce


    Perforce (P4) es una de las empresas de software independientes que están totalmente centradas en SCM y que luchan por llevarse el oro del mercado SCM contra los grandes gigantes del sector. Es todavía uno de los líderes del mercado en el rango de empresas medianas con equipos grandes, y tiene una presencia muy fuerte en ciertos nichos de mercado, como por ejemplo el sector de los video-juegos.
    Cuando salió a mediados de los 90, Perforce era uno de los sistemas más potentes y asequibles hasta la fecha. Estaba infinitamente por delante de VSS y de SVN aunque nunca llegó al nivel de Clearcase (ni en funcionalidad, y me refiero a branching y merging, ni en precio y complejidad), pero podía machacarlo en precio, rendimiento y facilidad de uso.

    Al ser un sistema centralizado y no demasiado bueno con ramas y merges (las ramas se implementan como subdirectorios) Perforce no parece ser la mejor opción de futuro, pero es innegable que es muy sólido, muy maduro y muy bien establecido en el mercado. Eso le ayudará a seguir creciendo. Ahora mismo, Perforce es todavía el sistema que gestiona todos los grandes repositorios dentro de Google. No está mal, ¿no?

    Y llegó la edad media


    Un tiempo de oscuridad en la que la mayor parte de los avances previos se perdieron y sistemas claramente menguados florecieron…

    Subversion


    Subversion fue concebido como un “CVS mejorado” y sus desarrolladores lo lograron: es mejor que CVS. Punto.

    Mientras que sistemas como Clearcase eran ya perfectamente capaces de gestionar el desarrollo paralelo mediante branching y merging, Subversion (SVN) es el responsable de que una generación entera de desarrolladores se formase con la idea de que hay que evitr las ramas y los merges a toda costa. Esto creó un daño global que todavía persiste y sólo está empezando a curarse gracias al auge de los DVCS.
    SVN estaba cerca de P4 en características y se extendió como una enfermedad contagiosa: más de 5 millones de desarrolladores usan SVN cada día en todo el mundo. ¡¡Tremendo!!

    Subversion es muy sencillo y evangelizó a todo el mundo en el “desarrollo en línea principal” (mainline development model). Una técnica propensa a errores en proyectos que no sean de juguete, ayudó a crear técnicas como “integración continua” como forma de “evitar merges”. Aunque la idea es buena, muchos de los conceptos en las que se basa surgen únicamente de las limitaciones de SVN.

    El mismísimo Linus Torvalds cargó contra Subversion cuando presentó Git en 2006.
    La realidad es que Subversion ya no está de moda y la mayor parte de los proyectos open source importantes en todo el mundo se han ido de Subversion durante 2009 y 2010. Un buen síntoma de lo equivocado que Subversion estaba. Pero todavía está muy extendido y no será extirpado en décadas.

    AccuRev


    Aunque nació en una época de oscuridad marcada por SVN, AccuRev fue diseñado como una forma nueva de hacer control de versiones. Su forma original de hacer las cosas todavía es novedosa parra muchos desarrolladores.
    AccuRev tiene un soporte muy bueno de ramas (“streams” en su jerga) y de merges. Ha jugado un papel esencial ayudando a empresas a moverse fuera de Clearcase y de sistemas más antiguos como CVS.

    El Renacimiento


    Tras una época de oscuridad una nueva generación de sistemas SCM rompieron el “status quo”. “El mercado de SCM es muy maduro y estable” repiten todavía algunos analistas como loros, pero la nueva generación ha entrado en escena rompiendo con todo lo establecido.

    Capaces de romper las cadenas de Internet y de trabajar desconectados (unplugged, como las estrellas de rock más “cool”), la nueva generación es también excelente haciendo branching y merging, lo que se conoció como “la madre de todos los males” durante la anterior edad oscura. Estos sistemas han podido romper con el pasado y proclamar “las ramas y los merges son buenos” marcando una nueva dirección.

    BitKeeper


    BitKeeper fue uno de los innovadores en el área de los DVCS. Diseñado por Larry McVoy (que antes trabajó en TeamWare, el sistema interno de control de versiones de la mismísima Sun Microsystems, construido usando SCCS como base y con una larga historia de evolución por detrás) saltó a la fama en 2002 cuando los desarrolladores del kernel de Linux comenzaron a usarlo. Entonces comenzó una guerra de email con algunos programadores protestando por usar un sistema comercial para gestionar el desarrollo del proyecto open source más conocido del mundo. Las cosas se pusieron todavía peor en 2005 cuando las luchas entre los programadores principales del kernel fueron a más. BitMover, la empresa detrás del producto, se comenzó a preocupar por que hicieran ingeniería inversa a su código, cortó el soporte a los proyectos open source e irónicamente desencadenó la creación de Git para cerrar el hueco creado.
    Para más información echa un vistazo a http://en.wikipedia.org/wiki/Bitkeeper.

    Git


    Linus Torvalds, el mismísimo creador de Linux, diseñó e implementó la primera versión de Git (prácticamente durante un fin de semana, al puro estilo hacker) para dar a sus programadores del kernel una alternativa a BitKeeper. Linus no sólo hizo el diseño original (simple, sencillo… ¡¡genial!!) sino que fue vital para promover el proyecto con su estilo único (mira See http://codicesoftware.blogspot.com/2007/05/linus-torvalds-on-git-and-scm.html). Durante su famosa presentación criticó duramente (vale, insultó abiertamente) a CVS, Subversion e incluso Perforce. Dijo perlas como “Subversion ha sido el proyecto con menos sentido que jamás se ha empezado”, “si te gusta usar CVS es que deberías estar en un centro mental o algo así” y “Deja de usar Perforce, es triste, pero es cierto”. Puedes odiarlo o adorarlo pero está claro que Linus dejó algo muy claro: la edad media de los controles de versiones ha pasado y ahora los DVCS dominarán el mundo, erradicando el miedo ancestral al branching y merging, un concepto vital en todos los sistemas de control de versiones distribuidos.

    Durante los siguientes años, y especialmente desde 2009, todos los proyectos open source importantes del mundo migraron de Subversion a Git (y aquí www.github.com ha sido clave mediante un fantástico sistema de hosting) convirtiéndolo en uno de los SCM más guays y potentes del mundo.

    Git se basa en una estructura de grafo acíclico dirigido (DAG, directed acyclic graph) en el que la principal unidad de cambio es el changeset (o commit en su jerga). Git implementa merge tracking completo pero a nivel de “commit” en lugar de a nivel de revisión (como, por ejemplo, hace Clearcase). Es muy rápido y las únicas pegas son el manejo de ficheros grandes y la restricción de tener que replicar los repositorios completos.

    Git está claramente influenciado por sus raíces como herramienta de desarrollo del kernel de Linux y obviamente no es el sistema más fácil de usar del mundo. Pero definitivamente será el SCM de la próxima década. Recomiendo leer el siguiente libro, que me parece buenísimo: http://peepcode.com/products/git-internals-pdf.

    Mercurial


    Mercurial (Hg) fue anunciado en Abril de 2005, también a toda prisa tras la decisión de BitMover de eliminar el soporte de su versión gratuita. Hg es el otro DVCS open source junto con Git. Incluso pueden conectarse bastante bien: Scott Chacon, el “evangelista de Git” y uno de los mejores escritores sobre SCM que he visto, preparó una integración bastante buena: http://mercurial.selenic.com/wiki/HgGit.

    Pero Hg es bastante diferente de Git en cuanto a su diseño interno. Ambos comparten el concepto de commit/changeset como unidad de cambio. Git implementa sus commits basándose en árboles, cada árbol apunta a un árbol más antiguo y así sucesivamente (de ahí lo del grafo acíclico). Con Hg cada changeset es una lista completa de todos los ficheros y directorios, y se le llama revlog (internamente la implementación del propio revlog está basado en deltas por lo que el almacenamiento es eficiente).

    Para más información sobre Hg, incluyendo cómo funciona internamente, merece la pena ver http://mercurial.selenic.com/wiki/Design y http://mercurial.selenic.com/wiki/DeveloperInfo.

    Mercurial también proporciona un merge muy potente pero su sistema de ramas es un poco diferente a los otros controles de versiones. Tiene “ramas con nombre” pero la preferencia es crear un nuevo repositorio como rama separada en lugar de tener varias “cabezas” (heads) dentro de uno sólo.

    Joel Spolsky (el de joelonsoftware.com, un blog buenísimo) ha escrito un tutorial muy bueno sobre Hg (hginit.com). La empresa de Spolsky, Fog Creez Software, acaba de lanzar Kiln, un SCM comercial aprovechando el esfuerzo open source hecho con Hg… No es listo ni nada el tío, y nosotros desarrollando un SCM completo… :P

    Darcs


    Darcs (Darcs Advanced Revision Control System) es otro intento de quitarse del medio a SVN y a CVS. Empezó en 2002 y ha continuado evolucionando desde entonces, llegando a la versión 2.5 en Noviembre de 2010.
    Las mayores limitaciones de Darcs han sido siempre el rendimiento y su forma un poco diferente de manejar la historia: en lugar de hacer “snapshots” (commits o changesets capturando un estado completo del proyecto en un instante dado) maneja “patches” pero de un modo que hace que recorrer la historia sea difícil de entender (un estado concreto puede no haber sido nunca una situación real del desarrollo).

    Bazaar


    Bazaar (bzr) es otro DVCS open source que intenta traer un poco de aire fresco al mundo del SCM. A pesar de ser menos usado que Git y que Mercurial, Bazaar introduce características interesantes como la posibilidad de trabajar también de forma centralizada (de hecho los DVCS puros no consideraban tener servidores centrales en su diseño original).
    Bazaar ha sido desarrollado por Canonical (sí, la empresa de Ubuntu!) y se pasó a licencia GNU al principio de 2008.

    Plastic SCM


    Plastic es un DVCS diseñado para ser usado en empresas en lugar de en proyectos open source a diferencia de Git y Mercurial. La primera versión de Plastic salió a finales de 2006 centrándose en branching y merging, con trazabilidad de merge completa (merge tracking) y soporte de renombrados en los merges. Proporciona un entorno de trabajo fundamentalmente gráfico, con muchas visualizaciones como por ejemplo el árbol de historia en 3D o el “explorador de ramas”. Esto es uno de los puntos que lo diferencian de los DVCS open source que están orientados a usuarios que usan más la línea de comandos.

    El objetivo de los desarrolladores de Plastic (recordad que soy uno de ellos) es llegar a equipos pequeños y medianos y cerrar el hueco que había entre los grandes sistemas como Clearcase y los de menor nivel como SVN, con un producto tan potente como los primeros, más fácil de usar, rápido, pero asequible (de hecho hemos lanzado una Community Edition gratuita en Noviembre de 2010).

    Plastic se centra en el concepto de desarrollo paralelo y recomienda el uso del patrón de “rama por tarea” (feature branches). Puede gestionar miles y miles de ramas sin problema. Plastic también es distribuido, soportando desarrollo desconectado, haciendo “push” y “pull” de ramas y gestionando posibles conflictos.

    Team Foundation Server


    Microsoft también ha querido meterse en el mercado de SCM/ALM y lanzó Team Foundation Server (TFS). Un esfuerzo para curar el dolor creado por su propio demonio: Source Safe.

    A pesar de que TFS no es muy bueno como sistema de control de versiones (es el chico nuevo en el barrio SCM pero usando tecnología de la década pasada) viene con un montón de herramientas accesorias como gestión de tareas, sistema de test integrado, etc, al más puro estilo “paquete corporativo con todo en uno”.

    No harás muchas ramas ni muchos merges ni desarrollo distribuido si vas a TFS, pero quizá tu empresa ya lo tiene junto a su subscripción de MSDN.
  • 18 comentarios:

    Un relato interesante y me agrada comprobar que el desarrollo es made in spain.

    En mi empresa utilizamos VSS y SVN, pero después de leer este artículo vamos a replantearnos el uso de Plastic SCM.

    Enhorabuena por este gran trabajo.

    Estimado: Muy bueno tu artículo, gran linea de tiempo histórica de los SCM. Con respecto a tu comentario: " en los comentarios de mi post original en inglés algunos empezaron a protestar diciendo “eh, qué pasa, que porque un software haya empezado hace 20 años quiere decir que ya no sirve?”. Evidentemente no me refiero a eso. (Hay un comentario muy gracioso de un tío que usa el “grep” y protesta amargamente… para troncharse)"... estoy totalmente de acuerdo contigo. Ta como dice Roger Pressman: "Pese a que el software no se desgaste, se deteriora" y como comentas el hecho de que los SCM viejos no evolucionen es señal de deterioro.

    Saludos desde Venezuela

    Fidel Ramos dijo...

    Un artículo fabuloso, divertido, bien contado y llenito de información. Yo he llegado a sufrir el dichoso VSS, aunque afortunadamente fue sólo 3 meses pero fueron más que suficientes para odiarlo por el resto de mi vida. Y totalmente de acuerdo con el "miedo al branching y el merge", es un problema grave que se va curando con los DVCS, pero aún queda una mayoría de desarrolladores acomplejados.

    Una anotación sobre Git: una de las pegas que mencionas, tener que replicar los repositorios completos, se subsanó en la versión 1.7, cuando se implementaron los sparse checkouts. El tema de los ficheros grandes también se resolverá en el futuro, o al menos eso prometen los desarrolladores.

    Como dice el autor del Pro Git Book, da igual si prefieres mercurial, git o bazaar, ¡pero usa un DVCS, no un Subversion!

    David dijo...

    Desde hace tiempo me dedico al desarrollo de sw, Ahora, concretamente, a la gestión de proyectos :-( (Supongo que son cosas que tocan con el tiempo..)
    Nosotros utilizábamos CVS hasta hace poco. Estaba prevista un migración de sistema, pero por el volumen del proyecto y la cantidad de subproyectos en desarrollo no lo hemos podido realizar hasta ahora. Hemos elegido GIT y la verdad; el resultado es muy bueno.

    Sin embargo, lo que comentas sobre el control de versiones a mano; no es historia. Conozco proyectos importantes (medido en volumen de personas trabajando y criticidad del sw. desarrollado) que siguen realizando esta práctica. ¿Lamentable? Si, pero cierto.

    Felicidades, un escrito muy interesante y agradable de leer.

    Anónimo dijo...

    Muy ameno y explicativo. Para que fuera perfecto le faltaría que el gráfico que muestra los distintos sistemas en el tiempo no mostrara solamente el año de su lanzamiento, sino los años durante los cuales se mantuvieron. -Ignacio Agulló

    Anónimo dijo...

    Y no poder cambiar de nombre a un fichero bajo CVS....? Qué, eh?

    Eran otros tiempos y eran otras máquinas, pero la capacidad de ClearCase de reutilizar los .o compilados por el compañero de cubículo a partir de sus .c o .cpp era legendaria. No tenía precio. Otra cosa es que precisara de admin propio (como cualquier DBA hoy en día para qué engañarse) o la máquina más gorda de la empresa únicamente para compilar y hacer releases... Su CofigSpec no era tan distinto al hash que te hoy en día te identifica el estado concreto de un arbol git.

    La eché de menos hasta que me presentaron a Subversion. Pero pasó casi una década hasta que la segunda dejó de hacerse la estrecha. No creo que fuera un paso atrás. Eran otros tiempos y ni sipu trabajaba en entornos tras salvajemente distribuidos como ahora.

    Hoy en día hay que pensar en términos de DVCS. Cierto. Pero sabeis qué? Todavía uso RCS de forma salvaje. Especialmente para los ficheros de configuración de máquinas.

    Anónimo dijo...

    Muy bueno el articulo, y muy divertido!

    jotaele dijo...

    Hola, muy bueno el post, pero me sorprende la parte de TFS; yo trabajo con TFS y estoy frecuentemente haciendo ramas y merges sin ningún problema. Y tiene merge tracking, y trazabilidad visual de changesets; de hecho de todo lo que comentas de Plastic, creo que lo único que no tiene es soporte de ramas distribuidas (aunque ya se ha comentado que posiblemente lo tenga en el futuro), y de todas formas no es algo que sea imprescindible en un entorno empresarial con equipos colocalizados.
    Lo de llamar "herramientas accesorias" a todo el sistema de construcciones automatizadas, gestión de elementos de trabajo, métricas, control de documentación de TFS... me parece cuanto menos curioso. Algunas de estas cosas dan tantos beneficios a un equipo de desarrollo como el propio VCS.
    Y tampoco entiendo muy bien lo de que está basado en tecnología de la década pasada.
    Por lo demás me ha gustado bastante el post y el repaso a la historia de los VCS..

    Un saludo!!!

    pablo dijo...

    @El eterno aprendiz: muchas gracias!! Y te agradezco mucho la confianza! Cuenta con nosotros para migrar a Plastic.

    pablo dijo...

    @Gerardo Barcia: de hecho es que muchas veces el software más maduro deja de evolucionar (lo compra una gran corporación, por ejemplo) y es precísamente lo que deja que otros puedan tener un hueco.
    Supongo que si, por ejemplo, Clearcase, hubiese evolucionado a tope desde hace 20 años... pues no habría mucho hueco para nuevos productos porque serían los número 1... pero la realidad no es así, la motivación se pierde, el equipo original se va, a veces en otras empresas la coordinación (al comprarlos) no es la misma... etc, etc.

    Gracias por el comentario de Pressman!

    pablo dijo...

    @Fidel Ramos: muchas gracias por el comentario!

    Una pregunta sobre lo que dices de Git: el "sparse checkout" te permite hacer co sólo de una parte... pero el clone lo tienes que seguir haciendo entero.

    Puedes hacer un clone con --depth pero luego ese repo no es totalmente funcional (no puedes hacer push con él). A menos que yo sepa...

    pablo dijo...

    @David: buen cambio el de Git! Lo del control de versiones manual... pues sí, un poco tremendo ;)

    pablo dijo...

    @Ignacio Agulló: lo de mostrar en el gráfico hasta cuándo han permanecido vivos... estaría bien pero es que me temo que TODOS siguen vivos todavía... estoy seguro ;)

    pablo dijo...

    @Anonymous: (el que habla de clearcase): totalmente de acuerdo!! Creo que el manejo del "wiking" (era así??) de ClearCase todavía no ha sido superado... Increíble. A mi me encantaría implementar algo así para Plastic pero me temo que la demanda es muy, muy baja (nadie nos lo pide).

    Estoy haciendo pruebas y prototipos (en mis ratos libres ;) ) con Dokan y con Fuse pero es que realmente hoy por hoy no sé si ya tendrá tanto sentido...

    pablo dijo...

    @jotaele: bueno, en primer lugar he intentado hacer un poco de sangre a TFS, quizá me he pasado ;)

    Las razones son:

    - Sigue usando "path space branching" que es el mismo modelo que usa SVN y Perforce. De ahí lo de "tecnología de la década pasada". Básicamente implica que crear una rama es una copia ligera del estado en un momento dado. De ese modo JAMÁS podrá manejar cientos de ramas porque ... es un dolor!

    - Los merges están limitados a mezclar con la rama padre, de otro modo te pide hacer "baseless merge" que, bueno, suena bastante a apaño y a quitar las ganas de hacerlo... Ningún sistema moderno te pide hacer eso.

    - Comparando con Plastic (ahora sí que barro para casa): pues desde el branch explorer a funcionar en cross-platform (incluido servidor) a ser distribuido, pasando por el rendimiento (vamos, TFS es leeeeeeeeeento como él sólo)

    Sobre lo de "herramientas accesorias", sí, me he pasado un poco. La verdad es que todo lo que traen es muy bueno pero... lo que no me gusta de las herramientas integradas es que parece que traen maravillas, todas juntas, pero luego una por una no son tan buenas: quiero decir, Jira estoy seguro que es mejor issue tracker que cualquier cosa que traiga TFS, y hay muchos controles de versiones mejores que TFS también, etc, etc...

    Pero bueno, no es sencillo luchar contra Microsoft y su TFS así que de vez en cuando hay que lanzarles alguna daga, no?? ;)

    Anónimo dijo...

    Excelente articulo en la empresa se usa TFS personalmente lo intento usar con eclipse y es una "PORQUERIA" el hacer un branch o un merge es un autentico dolor de cabeza y pensar que lo cambiaron de GIT que permitía hacer eso y mas. hay Dios cuando aprenderemos que mas nombre no quiere decir mejor marca.

    Anónimo dijo...

    Hola, yo iría un poco más allá y hablaría de defectos a la hora de criticar, pero bueno, además indicar que la integración continua es para solventar problemas de svn, me parece bastante arriesgado...
    Yo soy de los que le gusta evolucionar pero cuando se obtienen ventajas, no porque sea guay, y que mi control de versiones lo lleve un tercero no me gusta, a no ser que sea un proyecto open source...
    Bueno, que no me lío, artículo interesante por la línea histórica, pero que no me justifica el cambio por un tema de guay o no guay, hablando de alguien que sufre ramas y merge casi todos los días...
    Un saludo

    pablo dijo...

    @Anónimo con problemas de merge diarios :)

    Sobre el tema de los problemas de CI me refiero a esto: http://codicesoftware.blogspot.com/2010/08/branch-per-task-workflow-explained.html. Cosas como "keep the manline pristine", "don't shoot a moving target", etc, etc, etc. A ver si me pongo y lo escribo otra vez en Español.

    Lo del cambio de SCM: toda la razón. No te puedes cambiar porque sea guay (que ojo, es la razón por la que mucha gente se ha ido a Git, no nos engañemos!:P). Las razones que yo creo que hay para irse de SVN, por ejemplo, son:

    * Mejor sistema de ramas y merge -> plastic, git, mercurial

    * Distribuido -> plastic, git y mercurial

    * Visualización, facilidad de uso, rendimiento -> aquí barro para casa y pongo plastic, aunque evidentemente en rendimiento Git es un crack (de momento! :P)