Linus habla sobre ramas...

22:21 0 Comments

Hace unos meses Linus Torvalds escribía sobre algunos problemas que tenían en el desarrollo del Kernel con Git debido al uso de ciertos patrones de merge.

Como aprender de Linus es siempre interesante :P me gustaría entrar en detalle en los puntos que menciona y ver cómo aplicarlo para mejorar en desarrollos del día a día (no hace falta ser un kernel-hacker para sacar partido de esas técnicas). De hecho encaja con el patrón que nosotros recomendamos con Plastic aunque lógicamente él lo aplica a Git y sería también válido con cualquier otro SCM con buen soporte de ramas.

Las palabras de Linus


Esto es lo que escribió Linus, sólo he sacado un fragmento así que para tener la visión completa lo mejor es leer el link original.

The real problem is that maintainers often pick random - and not at all stable - points for their development to begin with. They just pick some random "this is where Linus -git tree is today", and do their development on top of that. THAT is the problem - they are unaware that there's some nasty bug in that version.


Y ahora intentaré traducir lo mejor posible:

El verdadero problema es que los “maintainers” a menudo cogen puntos aleatorios – y para nada estables – como partida de sus desarrollos. Simplemente cogen un “aquí es donde está el árbol de Git de Linus hoy” y hacen sus cambios sobre eso. Y ESE es el problema – no son conscientes de que hay un fallo muy feo en esa versión.


Disparando a un objetivo móvil


¿De qué está hablando Torvalds? Realmente de un problema muy bien conocido cuando se trabaja en “trunk o mainline” (vamos, sin ramas) como describía aquí hace ya algún tiempo en la sección titulada “don’t shoot a moving target!” (no dispares a un objetivo móvil).

El problema afecta duramente a todos los seguidores de la doctrina “mainline/trunk” (ya sabéis, SVN, CVS, VSS…) ya que se están actualizando constantemente a “lo más nuevo” quizá por miedo a hacer merges. Algunos intentarán solucionarlo con integración continua (CI) pero simplemente retrasarán el problema. Lo “malo” es que también afectará a quienes usen “ramas de característica” (feature branches) a menos que sigan todas las reglas (lo que nosotros solemos definir en el patrón de “rama por tarea”).

El problema con el que se encuentran en el desarrollo del kernel se ve en esta imagen:




El equipo del kernel usa ramas y todo pero ¿qué pasa si usan “master” como rama de integración (muy común, y correcto) y crean ramas desde “commits” que no están etiquetados (tagged)? (Como muestra el dibujo).

El problema es que al usarse la rama principal como punto de integración habrá “commits” intermedios (changesets) que no serán estables (especialmente si se usan los “fast-forward” merges de Git, que no me gustan un pelo, pero que supongo que no serán el problema de Torvalds ya que seguro que sabe usar Git muy bien, ¿no???). Entonces los programadores empiezan desde un punto inestable y… comienza la fiesta.

La clave son las líneas base



Nosotros hemos tenido exactamente el mismo problema con equipos usando Plastic pero que no entendieron bien al principio la importancia de tener líneas base (baselines, releases estables o como queráis llamarlas). Una vez que el código es estable: ¡etiquetadlo! Y cread las ramas de tarea SÓLO desde puntos estables!

Esa es la regla básica: cread líneas base con frecuencia (mínimo una a la semana en equipos de menos de 10 personas y más si el equipo crece) que por supuesto deben estar totalmente probadas (juego de test automático y cualquier tipo de prueba accesoria o manual que hagáis, de hecho esta es la parte larga de hacer integraciones, los merges, hoy por hoy, tienen que ser muy rápidos) y CREAD LAS RAMAS SÓLO DESDE BASELINES ESTABLES como muestra la siguiente figura:



De esta forma si algo falla en tu rama de tarea (o feature branch) sabes que… ¡es por tu culpa!, porque todos los tests estaban bien en la línea base (no sólo el juego rápido que puedes pasar en CI, también los que tardan horas).

Una regla muy, muy sencilla y con enorme ahorro en tiempo y dolores de cabeza!

0 comentarios:

Anunciando Plastic SCM Community Edition

22:51 1 Comments

Ha pasado casi 1 mes desde que hicimos el anuncio oficial de Plastic SCM Community Edition en nuestro blog en inglés.

Aunque somos una empresa española nuestra audiencia y nuestros usuarios son la mayoría de fuera y de ahí que siempre publiquemos primero en inglés.

Pero me parece que no viene mal incluir, aunque sea con un poco de retraso, la noticia del lanzamiento aquí.

El objetivo de Plastic SCM Community Edition es llegar a un número elevado de equipos de desarrollo pequeños y medianos (de ahí lo de hasta 15 usuarios de la licencia gratuita). Plastic es un sistema SCM de última generación (distribuido, con muy buen soporte de ramas, etc, etc) y nuestro objetivo con esta iniciativa es llegar a muchos equipos pequeños (que son mayoría en todo el mundo) dentro de empresas. ¿Por qué esto de "dentro de empresas"? Pues porque para proyectos open source, a pesar de que Plastic es ilimitado y gratis para ellos, ya hay alternativas excelentes como Git y Mercurial que han nacido en el entorno OSS y que están pensados para ese tipo de proyectos. Sin embargo Plastic ha sido diseñado y desarrollado para empresas. ¿Cuál es la diferencia? Pues (generalizando) que características como la seguridad basada en ACLs, integraciones nativas con los IDEs, almacenar los datos en bases de datos relacionales estándar (a elegir: Firebird, MySQL, SQL Server, Oracle e incluso SQLite) y por supuesto nuestra cuidada interfaz gráfica han sido una prioridad para nosotros y algo que sabemos que los desarrolladores valoran cuando buscan un sistema para su trabajo. La propia gestión de ramas (inmutables y persistentes en Plastic contra mutables y un potencialmente volátiles en Git, por ejemplo) está más orientada al uso en empresas.

Normalmente las empresas buscan herramientas que sean fáciles de poner en marcha, que tengan soporte comercial de primer nivel, que no les den muchos quebraderos de cabeza... y eso es lo que ofrecemos con Plastic para todo tipo de empresas y con CE para las más pequeñas.

Además consideramos que la situación económica actual fuerza a muchos equipos a no gastar dinero en software, de ahí también la iniciativa: facilitar y universalizar las mejores prácticas de SCM.

Plastic evoluciona muy rápido y podéis estar al día de todo lo que hacemos a través de twitter (@plasticscm).

Espero que nos ayudéis a extender el mensaje!

1 comentarios:

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: