Códice Software ES

Plastic internals: de 3.0 a 4.0

2011-09-21T01:38:00.000+02:00

Hoy va a ir de programación y estructuras de datos :). Voy a explicar en qué consiste el cambio fundamental en el que hemos estado trabajando en Plastic 4.0. Un cambio “core” de verdad que tiene mucho impacto y que creo que es muy interesante. Afecta al rendimiento, al sistema de réplica (lo que nos hace un DVCS), al mantenimiento del código, a la usabilidad…

Os habéis fijado en el nuevo Branch Explorer de 4.0? Dibujo una comparativa debajo:

Además de que los gráficos son mejores, ¿qué más veis? Los cuadrados de 3.0 son changesets y se han convertido en óvalos en 4.0, más grandes, porque ahora son más importantes. Pero hay otro tema: hay unas flechas entre los changesets que antes no existían. Esas flechas indican “parentesco”.

Es decir, ahora Plastic “sabe” que un changeset es padre de otro, mientras que antes no se guardaba esa relación.

Pero voy a bajar más, a las profundidades del sistema.

Almacenamiento de versiones

Un control de versiones guarda los cambios que haces en un árbol de código. Es decir, tú tienes un proyecto con ficheros y directorios, y por cada cambio se van guardando “revisiones” (que tienen muchas utilidades, desde volver atrás, revisar, etc, etc, pero no es el tema ahora).

Un ejemplo como el siguiente:

Primero tenemos un repositorio vacío.

Luego añadimos /src y /src/foo.c

Luego se modifica foo.c

¿Cómo se guarda eso en Plastic?

¿Qué hay en la base de datos de Plastic?

Instalad 3.0, con el backend de base de datos que más os guste (ya sabéis, Firebird, SQLite, MySQL, SQLServer… hay unos cuantos) y ejecutad las siguientes queries:

“select * from revision”

“select * from item”

“select * from childrenitem”

En lugar de conectaros al backend, es posible ejecutar las consultas con el comando “cm query” o “cm q” (hay que tener el permiso “advanced query” para poder hacerlo, cuestiones de seguridad).

Si veis las tablas que usa plastic veréis que son muy pocas. Ahora me centro sólo en tres que se pueden definir con el siguiente diagrama entidad-relación (no muy ortodoxo).

Cada elemento en el sistema es un ítem. Es decir, el directorio raíz (/) del ejemplo anterior es un ítem, “src” es un ítem y “foo.c” es un ítem. Pero un ítem es una “entrada abstracta”, es “que existes” pero no tienes ni un nombre asociado. (Ahora os he perdido, pero para dejarlo sencillo, un ítem es “la clase” y una revisión es “el objeto”).

Un ítem puede tener una o varias revisiones. Es decir, de “foo.c” podemos tener miles de revisiones (por eso sacar la historia en plastic es muy sencillo: “select * from revision where fiditem=xxx”).

Un ítem puede representar a un fichero o a un directorio.

Una revisión, si es fichero, puede ser texto o binario, si es directorio sólo directorio (es un poco más complejo porque también soportamos links y cosas así, pero de momento sirve).

Si la revisión es un fichero, tendrá un dato asociado (tabla revisiondata, los datos divididos en blobs de máximo 4Mb).

Si la revisión es un directorio entonces empieza lo bueno: puede tener una o más entradas “childrenitem”.

Al principio dije que “el ítem es abstracto” porque no tiene ni nombre ni datos. La revisión tampoco conoce su nombre, el nombre, en realidad, se guarda en el childrenitem.

Me explico: un fichero “foo.c” puede llamarse más adelante “bar.c” pero sigue siendo el mismo ítem, es más, ni siquiera se crea una revisión nueva del fichero al hacer un renombrado, sino una nueva versión del directorio que lo contiene y que le da nombre.

¿Ahora se entiende mejor?

Volviendo al ejemplo original:

Al principio sólo tenemos un ítem (el “famoso” ítem raíz) y una revisión (revisión cero) de ese ítem raíz en el changeset 0.

Entonces añadimos src y src/foo.c. ¿Qué quiere decir? Que se añaden dos ítems nuevos y dos revisiones nuevas.

¿Qué ocurre con los “children ítems”? Aquí viene lo interesante.

En el changeset 0 la tabla childrenitem está vacía.

En el changeset 1 la tabla childrenitem tiene el siguiente aspecto (recordad, acabamos de añadir /src y /src.foo.c al sistema):

¿Qué quiere decir?

Hemos creado la “revisión 1” del directorio raíz (antes era la revisión 0, se crea una nueva al añadir “src”).

Esa revisión 1 (DirRevId) tiene como dato una entrada llamada “src”, que es el itemId 10.

A su vez el directorio “src” tiene una primera revisión (revisión DirRevId = 2 en este caso (estoy usando un nº global para referirme a las revisiones, que es lo que usa plastic internamente)) que tiene como dato una entrada llamada “foo.c” del itemId 11.

Es decir, el directorio raíz es el ítem 0. “src” es el ítem 10. “foo.c” es el ítem 11. Sabemos que hemos creado una nueva revisión de “/” (raíz) que es la “1”. Y una revisión de “src” que es la “2” (no incluyo la revisión creada con los datos de foo.c porque no tiene que ver con “childrenitem”).

De este modo es como Plastic asocia los nombres de elementos (ítems) a entradas de directorio concretas.

Un segundo checkin

En el changeset 2 lo que ocurre es que se crea una nueva revisión del fichero src/foo.c.

¿Cómo se altera la tabla “revision”? Simple: se crea una nueva entrada para almacenar el nuevo cambio de foo.c

¿Cómo se altera la tabla “childrenitem”? No se modifica. No hay cambio en la estructura, luego no se modifica.

El selector entra en escena

Si habéis usado Plastic habréis visto alguna vez que cada workspace tiene asociado un “selector”. Ese selector es un texto que le indica al sistema “qué debe cargar” en el workspace. Es algo como:


repository "doc@diana.codicefactory.com:9092"
  path "/"
    branch "/main"
    checkout "/main"

Para muchos esto lo que hace es que le dice a Plastic que debe trabajar en la rama “main” y listo.

Pero en realidad no es tan simple.

Al estudiar “childrenitem” habréis visto que hay una relación entre el directorio y los ítems que debe cargar pero… ¿cómo sabemos qué revisión de un ítem determinado se debe cargar?

Es decir, si yo cargo la revisión 1 del root ítem, sé que debo cargar una entrada del ítem “src” (ítem 10). Esa información me la da la primera línea de “childrenitem”. Pero, ¿qué revisión de “src” debo cargar?

Es más, si nuestro repositorio ahora mismo (changeset 2) es algo como (en plan diagrama de objetos):

¿Cómo sabemos qué se debe “montar” como árbol de ficheros en un momento dado?

Es ahí donde entra en acción el selector. Las siguientes reglas:


repository "doc@diana.codicefactory.com:9092"
  path "/"
    branch "/main"
    checkout "/main"

En realidad quieren decir: “carga lo último de la rama “main” para todo lo que esté bajo el path “/” “.

Al resolver un selector Plastic lo primero que hace es buscar el “root ítem”:

¿Está el root ítem? Sí, es el ítem 0. (En caso contrario se daría un error fatal)

Cuál es la última revisión del root ítem? En nuestro caso la revisión 1.

Ok, coger la revisión 1.

¿Tiene datos? – Sí, es un directorio y como “dato” tiene la entrada de children ítem “src”.

¿Qué ítem es src? – Es el ítem 10.

Ahora el proceso se repite recursivamente para cada directorio: ¿cuál es la última revisión de “src”? Es la revisión 2.

¿Tiene datos la revisión 2? Sí, tiene una entrada “foo.c –item 11”.

¿Cuál es la última revisión de foo.c? Es la revisión 4, la que hemos creado en el changeset 2.

Por tanto, el selector anterior cargaría el siguiente árbol:

Que es el árbol que se resuelve en el changeset último en este momento o changeset 2.

(No he incluido el manejo de ramas en todo el ejemplo, pero sería lo mismo, realmente el selector no dice “cuál es la última revisión del ítem 10” sino “cuál es la última revisión del ítem 10 en la rama main”)

Qué pasaría si ahora modificásemos el selector de la siguiente forma:


repository "doc@diana.codicefactory.com:9092"
  path "/"
    branch "/main" changeset “1”
    checkout "/main"

Ocurriría que la respuesta a las preguntas anteriores nos daría el siguiente árbol:

Destacando lo que ha cambiado respecto al selector anterior.

Un grafo dinámico

Es decir, Plastic NO puede resolver un árbol de directorios si no se le indica un “selector” que le ayude a “seleccionar” la revisión adecuada al ir cargando cada nivel de directorios.

La carga de árboles (resolución de selector o “solvepath” como le llamamos en el equipo) no funciona exactamente como la he descrito. Es decir, sí que funciona así a nivel lógico pero está optimizada para minimizar las consultas a la base de datos, utiliza cachés intermedias, etc, etc (ha sido uno de los campos de optimización desde los primeros pasos del proyecto).

Este grafo dinámico da una enorme flexibilidad: un movido, un renombrado, se trazan a nivel de directorio, pero no se tiene que crear una nueva revisión de los ficheros implicados (o directorios).

Mediante esta estructura (y un uso adecuado de selectores) es como se implementa el sistema de “herencia de ramas”:

Al cargar la “última revisión de /main/tarea001” de foo.c lo que se hace es: ¿hay una revisión en la rama “tarea001”? Sí, cogerla.

No? Entonces coger la última (o la correspondiente según la estructura de la “smartbranch” task001) de la rama “padre” /main.

Y así es como funciona la herencia de ramas…

Los selectores y la estructura de gráfico dinámico dan una gran flexibilidad: es posible tener estructuras diferentes del árbol montando “diferentes reglas”: podrías coger un directorio de una rama, que cargue el contenido de los ficheros de otra, montando una estructura totalmente dinámica.

En realidad una cosa es lo que “existe” en el repositorio y otra lo que el usuario “ve” en el workspace, muy al estilo de las “vistas” del viejo ClearCase.

Como veis, el sistema hasta 3.0 tenía una enorme flexibilidad.

Cambios en 4.0

Pero a cambio de esa “flexibilidad” también había una gran “complejidad”. Por un lado se necesita un tiempo para acostumbrarse al mecanismo “grafo dinámico” aunque mediante nuestras herramientas intentamos hacerlo lo más transparente posible.

Por otro, impone ciertas complicaciones a la hora de trabajar en modo distribuido (DVCS), como por ejemplo garantizar que un changeset en un repositorio es exactamente igual al replicarlo a otro, porque dependerá de las revisiones que existan en el destino y de cómo se carguen. Un pequeño lío.

Además la carga, aunque optimizada, era pesada…

¿¿Qué hemos cambiado en 4.0??

Pues en realidad usamos la misma base de datos!!!

En serio, la misma estructura, pero con un pequeño “hack” en cuanto al significado.

¿Recordáis la tabla childrenitem?

Pues hay un pequeño cambio en 4.0: en lugar de que cada entrada apunte a un itemid, apunta a un revid… (¡!!!!)

¿Qué significa esto?

Significa que nos ahorramos la fase de resolución porque ahora cada árbol es “hardcoded” una vez que se hace checkin. Un changeset tiene una estructura fija, más sencilla de entender, más rápida y eficaz, mucho mejor en la réplica. No hay que interpretar una serie de reglas para resolver un árbol.

Perdemos algo de flexibilidad, es cierto, no se pueden hacer maravillas como modificar un directorio en una rama, cambiando el nombre a un fichero y nada más, y poder montar un selector complejo que altere el nombre de un ítem concreto sólo en nuestra vista jugando con esas ramas. No puede hacerse y me dolió mucho quitarlo pero… era una flexibilidad con un gran poder y… muy poca responsabilidad ;)

4.0 es más “DAG” (algún Git fan por aquí?), más rápido, más simple, y este pequeño cambio (un solo significado dentro de una tabla) define un nuevo mecanismo de merge, de réplica, de checkin, de diferencias… de sincronización con otros SCMs… de todo!!!

Merges parciales?

2011-09-12T01:11:00.000+02:00

El tema, al primer vistazo, puede sonar un poco rebuscado, así que voy a intentar simplificarlo al máximo.

¿Qué es un merge parcial?

Hacer un “merge parcial” consiste en, dada una rama o un changeset (commit, en términos Hg/Git) que se denominará “origen del merge” (src), hacer “merge” (o integrar) en una rama destino sólo parte de los elementos modificados en el origen del merge.Con una imagen seguro que se entiende mejor:

El “ninja coder” ha modificado unos cuantos ficheros en una rama, ¿qué pasaría si sólo quiere integrar render.c y readme.txt pero ser capaz de integrar el resto más tarde?

Nota: Las "flechas" entre changeset y changeset indican "parentesco". Es decir, el cset 0 es padre del cset 1. Las flechas indican parentesco y no secuencia, al estilo de lo que Scott Chacon dibuja en Getting Git (slide 165). Por cierto, es también como nuestro branch explorer de 4.0 dibuja las cosas.

Objetivo

Mi objetivo con este post es: que me enviéis vuestra opinión sobre la importancia, o no, de los "merges parciales" en vuestro equipo. Podéis dejar comentarios en este post o bien contribuir a este thread de stackoverflow: http://stackoverflow.com/questions/7323662/dvcs-partial-merge-git-hg-merge-tracking

¿Por qué esto es importante?

Para algunos de vosotros quizá la explicación de arriba os suena ya a hablar de un caso rebuscado. ¡No sabéis cuánto me alegro! Me alegro porque quiere decir que no necesitáis merges parciales, lo que me simplifica mucho la vida.Los merges parciales son importantes porque todos los DVCS (Distributed Version Control System) como Git o Mercurial (Hg) carecen de merge parcial. ¿Es esa una enorme carencia? Es lo que me gustaría que me contaseis.

Para los usuarios de Subversion que se están riendo…

… con una risa contagiosa y malvada diciendo “ya os lo decía yo, los DVCS esos son una patata, mejor quedarse con el viejo SVN!!”.Vale, ¡estáis listos! Esto de los merges parciales afecta a sistemas como Git o Hg (que no lo tienen) frente a sistemas como Clearcase o nuestro Plastic <=3… vosotros, queridos usuarios de SVN, no tenéis este problema… ¡¡estáis todavía peor!!

En detalle

Vamos a ver qué significa eso de los merges parciales, con imágenes:

Primero el “ninja coder” hace un merge de dos de los cuatro ficheros que modificó. Luego:

Un sistema sin “merge parcial” con trazabilidad a nivel de changeset, crea un “merge link” entre changesets que se han mezclado, pero no tiene modo de saber si todo el contenido (todos los ficheros) fue mezclado o no. Asume siempre que el contenido completo fue mezclado.

Un sistema con “merge parcial” (como lo era Plastic SCM hasta 4.0) identifica la historia de merge ítem por ítem mientras que en los DVCS modernos la “trazabilidad de merge” va a nivel de changeset. Implica que hay muchos cálculos (uno por fichero) en lugar de uno sólo para todos.

¿Cómo es de importante?

¿Integras primero partes de una rama y luego el resto? Si es así, o cambias de método de trabajo o el sistema de merge “parcial” no servirá demasiado.

Ventajas y desventajas

No soportar “merges parciales” hace que el mecanismo de merge de ramas sea mucho más rápido. La desventaja es que no es sencillo (se puede hacer dividiendo changesets) mezclar sólo parte de una rama.

Opiniones

En la beta de 4.0 (igual que en todos los DVCS incluyendo Git y Hg) el merge tracking es a nivel de cset, lo que implica que no hay soporte para merges parciales.

Enviadnos opiniones para saber cómo de importante es soportar merge parcial y actuar en consecuencia!

Como decía: podéis dejar comentarios en este post o bien contribuir a este thread de stackoverflow: http://stackoverflow.com/questions/7323662/dvcs-partial-merge-git-hg-merge-tracking

Test hacker – Plastic SCM

2011-09-09T12:17:00.000+02:00

Estamos buscando a un auténtico "test hacker" que nos ayude a mover Plastic SCM al siguiente nivel.

¿Qué buscamos?

Ingenieros con muchos conocimientos de programación y capaces de:

Verificar cada una de las nuevas características y bugfixes de Plastic: exploratory testing y definición de nuevos juegos automáticos de tests (e incluso colaborar con el resto del equipo en su implementación), detección de problemas de usabilidad, reducción de regresiones.

Continuar desarrollando el entorno de testing automático: ejecución más rápida de los juegos de pruebas automáticas, paralelización, desarrollo de tests de carga en cluster, migración a Amazon EC2… y todo lo que nos puedas aportar y que estamos deseosos de aprender!

No buscamos: experiencia en “ejecutar guiones de tests” sin conocimientos actualizados de programación. No pasamos “guiones de tests a mano”, eso lo tenemos automatizado, necesitamos complementar los tests automáticos y continuar mejorándolos, aumentándolos y haciendo más rápida su ejecución.

¿Qué te ofrecemos?

Competir contra software de nivel mundial como Perforce, Git, Mercurial, Subversion, ClearCase, Team Foundation Server, AccuRev… Trabajar en control de versiones es pasar a primer nivel, luchar contra los mejores del mundo en el sector, cada día.

Problemas de software complicados, muy complicados.

Desarrollar en áreas muy diferentes: desde server a cliente GUI, web a capa de red, base de datos a gráficos 3D. Lo de “hacer siempre lo mismo” simplemente no ocurre.

Flexibilidad y libertad: controlar, de verdad, cómo y cuándo trabajas.

Incorporarte en un gran momento cuando todavía se puede ser parte del núcleo.

Remuneración económica muy competitiva.

¿Te interesa?

Si te interesa envíanos tu currículum a: cv@codicesoftware.com y cuéntanos por qué eres el profesional que nos hace falta.

Mucha más información…

… por si tienes ganas de conocer más.En cada proyecto competimos con productos como Perforce (el sistema de control de versiones que usa Google... sí, no usa Git, ni SVN!!, y por cientos de miles de desarrolladores de videojuegos), ClearCase (de IBM), AccuRev, Git (el sistema DVCS iniciado por Linus Torvalds), Subversion (SVN)... La mayoría de nuestros clientes y de las descargas de nuestro software son de Estados Unidos, Inglaterra, Australia, Alemania...Códice arrancó en 2005 y está formada por jóvenes ingenieros (cada vez menos jóvenes ;) que creemos firmemente en crear software que compita a nivel mundial. Y no sólo lo creemos, lo logramos día a día.Algunos datos que te pueden interesar:

Fuimos la primera pyme en lograr CMMi 2

Estamos iniciando nuestro Sprint 113 de Scrum

Automatizamos las pruebas de software con tests unitarios, de smoke (línea de comandos automatizada, somos los creadores de PNUnit, la extensión de NUnit para tests paralelos que puedes encontrar en NUnit 2.5) y Gui (TestComplete), que en total suman más de 30 horas de ejecución, que paralelizamos con VMWare y logramos dejar en "sólo" 4-5 horas. El siguiente paso, y ahí podrías colaborar, es usar EC2 de Amazon.

Desarrollamos el único DVCS comercial que existe (y tenemos que darnos prisa porque la competencia se mueve)

Nos encargamos de la release en Solaris del proyecto Mono, y hemos hecho muchas contribuciones (colaboramos en el desarrollo del nuevo Garbage Collector que se probó mediante tests de carga de nuestro servidor “plasticd”, plastic daemon)

Usamos Java, C y mucho, mucho C#, de hecho, no encontrarás otra empresa que use C# en Windows, Linux, MacOS X, Solaris, FreeBSD... (y OpenBSD pero de forma no oficial ;) )

Códice está respaldada financieramente por un fondo de capital riesgo. En medio de una de las mayores crisis económicas de los últimos tiempos nuestra tecnología convenció a un fondo tecnológico puntero, algo que creemos que da confianza.

Ofrecemos una remuneración muy competitiva, casi seguro que superior a la mayoría de ofertas que hayas visto.

Podrás mejorar tu inglés a diario (de hecho, cuanto más nivel tengas, mejor)

Participarás en el diseño de software para desarrolladores, para gente como tú, lo que supone uno de los retos más apasionantes para un ingeniero ya que conocerás a fondo el entorno y podrás aportar soluciones (somos usuarios de nuestro propio software!)

Plastic lo usan empresas como HP, VVisions (te suena el "Guitar Hero"?), DHL... y también pequeños equipos de desarrollo en todo el mundo. Uno de nuestros primeros clientes fuera de España fue una unidad del ejército de Estados Unidos, a finales de 2007.

Hemos participado en eventos como SDWest y Game Developer's Conference (San Francisco), posteamos y escribimos en sitios como DrDobbs (DDJ), fuimos finalistas de los Jolt Awards hace un par de años...¿Qué nos gusta ver en las entrevistas?

Que dominas los temas de los que hablas: si hablas de Java o .NET… ¿nos podrías explicar lo qué es el Garbage Collector? No es tan difícil…

Que leas libros de software.¿Te suena el Code Complete?, Implementation Patterns, Clean Code…

Que controles lo que has aprendido: ¿semáforos?, ¿threads?

Que te encante desarrollar softwareSi estás interesado escríbenos a cv@codicesoftware.com

Bienvenido a la Jungla!!

2010-12-13T09:47:00.002+01:00

Nota: creo que es recomendable escuchar esta música mientras leéis el post.

Y ahora... Welcome to the GitJungle!!

Acabamos de lanzar GitJungle, un pequeño explorador de repositorios de Git que utiliza nuestra tecnología de visualización de ramas de Plastic SCM (BranchExplorer, BrEx) y básicamente permite ver los repositorios de Git desde un ángulo diferente... :P

Cómo descargarlo

Muy fácil, hay que ir a nuestra nueva página de labs, leer un poco más sobre GitJungle y después descargar los binarios (recordad que para Mac y Linux necesitaréis tener Mono instalado).

Cómo usarlo

Bueno, supongo que no tengo que explicarle a nadie interesado en GitJungle cómo clonar un repositorio de Git pero para que la entrada quede lo más completa posible:

$ git clone https://github.com/jquery/jquery.git
$ cd jquery.git
$ gitjungle .

Y entonces tendremos los siguientes gráficos!!

Action not words!

Un vídeo de GitJungle en acción aquí:

Peligro - zona de experimentos!

Acabamos de lanzar la beta de GitJungle!. Es un experimento, creemos que tiene muy buena pinta y todo eso, pero no deja de ser una beta, así que no está libre de posibles problemas. Si encuentras alguno, ya sabes, ¡dínoslo!

Lo bueno es que hemos usado el mismo núcleo de código del Branch Explorer de Plastic, lo que nos permite mostrar la historia de forma horizontal en lugar de vertical como hacen GitK y otras herramientas de Git. Así que bienvenidas sean las sugerencias, los aplausos o las críticas más mordaces!

¿Por qué nos ha dado por sacar una herramienta para Git?

Como todos sabéis lo que hacemos es desarrollar y vender Plastic SCM, el DVCS comercial más potente jamás creado, el que tiene mejores visualizaciones, soporta diferentes "backends" de base de datos, seguridad integrada con soporte de ACLs, el mejor sistema de branching y merging.... vale, vale, paro ya con el rollo de marketing! ;)

Bueno, al tema, que sí, que nos centramos en Plastic, sin embargo desarrollar GitJungle nos ha llevado muy poco tiempo así que... ¿por qué no compartirlo?

Pero, respondiendo a la pregunta: estamos trabajando a tope en la próxima versión de Plastic SCM y nuestro objetivo es que sea más interoperable que nunca y que tenga sincronización bidireccional con Git!

También, Plastic SCM es un DVCS para empresas mientras que Git (aunque puede usarse en empresas) está muy enfocado a proyectos Open Source así que, ¿por qué no colaborar? La verdad es que Git está enseñando los conceptos de branching y merging a todo el mundo y educando a los desarrolladores en "desarrollo distribuido". Todo eso es muy bueno para Plastic porque así los usuarios aprecian mucho mejor qué es lo que ofrecemos. (Nota: NO, Plastic NO está basado en Git, hemos tenido que trabajar duro para desarrollar nuestro propio sistema, capa de base de datos, algoritmos de merge, seguridad y... bueno, y todas las cosas divertidas!! :P)

Linus habla sobre ramas...

2010-11-29T22:21:00.003+01:00

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!

Anunciando Plastic SCM Community Edition

2010-11-28T22:51:00.003+01:00

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!

La historia del control de versiones

2010-11-26T12:01:00.003+01:00

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.

Agile Retrospectives (III): Actividades (I)

2010-09-28T18:42:00.001+02:00

Actividades para preparar el escenario.

Check-in

Haz una pregunta y que cada miembro la vaya respondiendo, por turnos, en una o dos palabras. Ejemplo: ¿Cuál es tu impresión del último sprint?

Focus on / Focus off

Prepara pares de palabras o conceptos interesantes, forma grupos en los cuales cada grupo discuta un par diferente.

ESVP

Cada miembro anota, anónimamente, sus impresiones sobre hacer el retrospective según su opinión o estado de ánimo: Explorer (interés alto), Shopper (interesado pero que sea rápido que tengo que volver a mi trabajo), Vacationer (estoy aquí por perder tiempo), Prisoner (estoy aquí por obligación; preferiría estar trabajando).

Working agreements

Hacer grupos. Cada grupo propone una serie de ideas para comportamientos efectivos y mejorar la productividad. Al final se exponen y se eligen de 3 a 7 propuestas. El equipo al completo se hace responsable de que todos lo cumplan.

Actividades para recopilar datos.

Timeline

En grupos, decidir eventos, actividades, etc. importantes durante la iteración que acaba de terminar. Momentos clave, momentos buenos, malos, etc. Recopilar los datos y elaborar una línea temporal común.

Triple Nickels

Formar gurpos. Cada miembro tiene cinco minutos para anotar acciones de mejora en un papel. Transcurrido ese tiempo, se lo pasa el miembro de su derecha. Al final, se recopilan las notas y se ponen en común. El objetivo es tener la mayor cantidad de ideas posible. Si el equipo es menor de 7 u 8 miembros, hazlo en un sólo grupo. Se escriben sentimientos, eventos, reacciones importantes que hayan ocurrido durante el sprint.

Color code dots

Usar junto con Timeline. Una vez tenemos el timeline, cada miembro pinta un círculo rojo o verde según la impresión que le ha causado cada evento del Timeline. Al final, analizar qué actividades han dejado una mejor / peor impresión y discutir el porqué.

Mad Sad Glad

Identificar con colores en el timeline qué períodos hicieron sentir a cada miembro estresado, triste o contento. Extraer conclusiones y analizar períodos mejores y peores.

Locate Strenghts

Preguntar, por parejas, los puntos fuertes del sprint. No se trata de dialogar ni discutir, sino de entrevistar.

Satisfaction Histogram

Hacer un historgrama con las impresiones recogidas en cada sprint de cada miembro. Acota el grado de satisfacción y que anónmamente, cada miembro escriba su número. Variación: en lugar de impresión personal, valoración como equipo. Analizar resultados al final y evolución del historgrama.

Team radar

Se establece una serie de factores u objetivos a analizar y cada miembro puntúa desde el punto de vista del equipo: ¿cómo de bien hace el equipo el factor …? Discutir los resultados.

Like to Like

Cada miembro destaca los eventos que han ido especialmente bien en su opinión. Es importante analizar la opinión de cada uno: cada miembro elabora una lista con 3 cosas que hay que dejar de hacer; 3 cosas que hay que seguir haciendo y 3 cosas que habría que empezar a hacer. Se van destapando uno a uno estos factores y los demás destapan “cartas de calidad” que manifiestan su valoración. Para agilizar, la última carta en ser destapada queda eliminada. Dar tiempo a pensar antes del destape.

Y en la siguiente entrega…

Actividades para generar reflexiones, para decidir qué hacer y para cerrar el retrospective.

Referencias:

Agile Retrospectives – Making good teams great

Esther Derby, Diana Larsen

Recortes, el arma secreta de la gestión de proyectos

2010-08-30T11:50:00.003+02:00

Una nueva entrada en el blog de agile-cyl que creo que es interesante! :)

http://agilecyl.org/2010/08/26/recortes-el-arma-secreta-de-la-gestion-de-proyectos

Nuevo "view switcher" y vídeos en Mac

2010-08-04T11:59:00.004+02:00

En 3.0 hemos introducido en la GUI una característica que muchos usuarios estaban esperando: poder cambiar de vista activa usando teclas. Algo básico, pero que todavía no teníamos.

Así que hemos desarrollado un "view switcher" (cambia-vistas): pulsando CTRL-TAB se muestra una ventana que te permite ir saltando de una vista a otra.

He grabado un vídeo corto, esta vez en Mac OS X en lugar de en Windows, para que se vea un poco de cómo queda Plastic en Mac.

Por cierto, que es interesante, para los desarrolladores de Mono, ver como su MWF queda con un poco de diseño ;)

Queda bien, no?

Tengo algún vídeo más en Mac, mostrando el branch explorer (de nuestro repositorio, así que montones de ramas), que subiré en los próximos días.

Pero, primero, un vídeo más en Mac, esta vez mostrando la nueva "code review", una de las características importantes en 3.0. (Recordad que el vídeo se puede poner a pantalla completa y en HD)

Lo bueno de esta característica es que todos los usuarios de Plastic tendrán ahora code review integrada, y además es, que sepamos, la primera code review distribuida...

Xmerge para integrar código refactorizado

2010-07-29T16:51:00.003+02:00

Llevamos unos días con bastante movimiento. Primero lanzamos 3.0, luego anunciamos el nuevo Xdiff, después hicimos una comparativa entre varios controles de versiones bajo escenarios de carga, y machacamos a Perforce y a Subversion, así que ahora voy a ver si puedo explicar, de la forma más simple posible, cómo funciona el nuevo Xmerge.

Mezclando código que se ha movido

Si no te aclaras muy bien con lo que estoy explicando sobre diff y merge, creo que sería mejor que empezases con el post que escribí la semana pasada sobre Xdiff. Hay un vídeo corto y todo por si no te apetece mucho leer :-P.

Básicamente Xmerge aplica la tecnología que hemos desarrollado para Xdiff dentro del proceso de merge (mezcla o integración). El escenario es muy sencillo:

Tenemos un fichero con algo de código

Tu vas y mueves un método de sitio, desde la parte de arriba hasta abajo, por ejemplo (porque prefieres los privados al final, o símplemente porque sí).

Mientras tú haces eso, en mi propia rama de tara, yo voy y cambio el método en su posición "original".

Y ahora te toca hacer el merge... ¿Resultado? Pues un rollo a menos que tengas Xmerge :-P

Código original

Vamos a empezar con un código muy sencillo como el de la siguiente imagen:

Alguien mueve el método "multiply" hasta abajo

El método "multiply" es privado así que vamos a ponerlo al final.

Una vez movido comprobamos las diferencias en Plastic:

Y mientras tanto alguien 'refactoriza' el método original

El método "multiply" no es precísamente una maravilla... :). Vamos a cambiar alguna cosa:

Estructura de ramas antes de integrar

Aquí está la estructura de ramas tal y como la dibuja Plastic justo antes de hacer el merge (recuerda que he usado una rama diferente para cada cambio, rama por tarea... lo de siempre!).

Ejecutando xmerge

Cuando hagamos el merge de las dos ramas hacia /main (bueno, la primera no va a protestar porque es un cambio directo) obtendremos un conflicto como el siguiente:

Lo bueno de Xmerge es que lo detecta y te muestra un botón 'xmerge' para avisarte de que te puede echar una mano para resolver este lío. (Haz clic en la imagen de debajo para hacerla más grande).

Vale, de qué va esto?

Xmerge detecta que el bloque de código que estás intentando mezclar ha sido movido. Así que detectará también a dónde se ha movido y lanzará un "submerge" sólo de los fragmentos involucrados. Así puedes resolver el conflicto de manera más simple y una vez que lo tengas, el resultado se "pegará" en la herramienta de merge original.

No sé si queda claro porque es un caso avanzado, pero ninguna herramienta es capaz de hacer algo como esto... Es la tecnología de merge más avanzada del mercado! :)

Resultado del cross-merged

Allá va:

Y la peli...

Bueno, para los que prefieran "ver la peli en lugar de leer el libro"... :)

Ponedlo a pantalla completa porque lo he grabado a 1024x768 así que debería verse muy bien.

Conclusión

Bueno, no es la funcionalidad más sencilla de explicar de todas las que hemos desarrollado así que... preguntad!

Esta es nuestra segunda versión de Xmerge. La primera (en Plastic 2.8) era ya capaz de hacer todo lo del "submerge" pero el usuario tenía que localizar el código movido a mano. Ahora es el propio Xmerge el que es capaz de localizar el código movido (de eso va toda la tecnología, claro).

Estamos preparando más cosas en esta línea, así que atentos al blog :)

Xdiff para ver diferencias de código movido

2010-07-22T13:27:00.002+02:00

Una de las características más importantes que acabamos de sacar para 3.0 es el nuevo Xdiff. Lo llamamos "cross-diff" porque localiza código movido y lo solíamos dibujar en papel con líneas que se cruzaban entre el código original y el movido...

Bueno, vamos a ver por qué esto es tan bueno...

Empecemos con un trozo de código como el siguiente:

Y entonces movemos un fragmento un poco hacia abajo:

Y después de haberlo movido modificamos el código como se ve aquí:

Y a ver qué es lo que puede hacer el Xdiff de Plastic!

Como veis puede localizar código que se ha movido incluso aunque después se haya modificado. Y se puede hacer click en el botón de "mostrar diferencias" que lanza un nuevo "subdiff" con el fragmento que ha detectado como movido para poder ver en detalle qué ha cambiado.

Mola, o no???

Podemos detectar el código movido en cualquier lenguaje de programación porque el algoritmo no se basa en parsing sino en detección de texto plano (os suena Levenstein?? :-P).

En el siguiente vídeo se puede ver el Xdiff en acción.

Espero que os guste!

Acabamos de lanzar Plastic SCM 3.0!

2010-07-19T15:34:00.005+02:00

¡¡Plastic SCM 3.0 ya está disponible para descargar!!

Nos ha costado casi 400mil líneas de código y 83 sprints (usamos SCRUM) llegar aquí desde la versión 1.0, pero 3.0 es la mejor "release" que hemos hecho hasta ahora.

Por un lado tenemos muchas características nuevas: desde Xmerge/Xdiff (capaz de mostrar diferencias en los merges y en las diferencias, algo que ninguna otra herramienta del mercado tiene!) hasta revisión de código integrada, y por otro muchísimas mejoras de usabilidad (cosas que nos habían pedido varias veces, otras que hemos encontrado nosotros mismos) y como siempre de rendimiento (3.0 es un 30% más rápido que 2.9 en nuestras pruebas de carga).

En Códice tenemos un equipo mucho más pequeño que el de nuestros competidores: desde Accurev (www.accurev.com) a Perforce (www.perfoce.com) pasando por Clearcase (el sistema más extendido a nivel empresarial, ahora de IBM), Team Foundation Server (el ALM de Microsoft, que a nivel de control de versiones es un chiste comparado con Plastic) e incluyendo Subversion y los otros DVCS open source como Git y Mercurial, todos tienen un equipo de desarrollo al menos cuatro veces más grande (echad un vistazo al número de 'committers' diarios en Git). Por eso estamos especialmente orgullosos de 3.0, porque nuestro 'pequeño equipo' es capaz de producir uno de los SCMs más avanzados del mercado: realmente Plastic proporciona de todo, desde distribuido (ningún otro sistema comercial excepto BitKeeper es distribuido, por mucho que diga su marketing engañoso! :-P) hasta manejo ágil y avanzado de ramas, representaciones gráficas, etc. La verdad es que un equipo más pequeño no es una desventaja, más bien todo lo contrario.

Mi objetivo para las próximas semanas es reactivar el blog en español. La verdad es que casi todos nuestros clientes hablan inglés, pero creo que no viene nada mal reforzar un poco el "blog nativo". Espero contar experiencias sobre el desarrollo de 3.0, así como de nuestro propio proceso (SCRUM + branch per task + gestión de releases + testing!) (bendito testing automático!).

Pero ahora vamos a por la 3.0, ¿qué hay de nuevo?

Revisión de código integrada (y distribuida): hace unos meses desarrollamos una integración con ReviewBoard. No está mal y aunque algunos de nuestros clientes lo usan (os suena el juego GuitarHero??? Pues la gente de Vicarious Visions usa Plastic + ReviewBoard) al final nosotros nunca lo pusimos en marcha. ReviewBoard, como casi todos los sistemas de 'code review', recibe un parche (patch) y es eso lo que analiza. Para nosotros lo natural es revisar ramas y changesets, y hacerlo de esa forma, no mediante un "intermediario". Así que añadimos esa funcionalidad para 3.0: desde una rama puedes crear una "code review" y añadir comentarios. Muy sencillo. Y lo mejor: también se replica! Es decir, que acabamos de lanzar el primer sistema de code review distribuido del mercado. :)

Shell extension: integración con el Shell de Windows. Nada nuevo porque seguro que todo el mundo ha usado TortoiseSVN (o TortoiseHg, muy común en estos días también), pero algo que nos habían pedido varias veces. Por supuesto, no nos hemos limitado a las operaciones básicas y ahora puedes usar todo Plastic desde la "shellext": sacar vistas, gráficos, etc, etc... Eso ya no lo hacen las "tortugas" :)

Nuevo importador para Subversion. Bueno, en primer lugar hemos vuelto a escribir el "SVN importer" (los desarrolladores que han trabajado en esto durante meses bromeaban diciendo que ya no trabajaban en una empresa de software sino en el negocio de la "importación-exportación" :-^) que ahora es más rápido, más usable (el wizard es mejor, también la ayuda) y soporta conexión directa mediante el ra_api (raw access) en lugar de sólo automatizando la línea de comandos. Lo hemos probado con más de 100 repositorios de SVN con éxito.

Importador de Perforce: desde que estuvimos en GDC 2010 han venido muchas empresas del sector de los video-juegos interesadas en abandonar Perforce para venir a Plastic. ¿Los motivos? Los de siempre: necesitan branching y merging a tope, como todo el mundo! Y necesitan un sistema distribuido, y que sea gráfico... Bueno, el caso es que hemos desarrollado un importador de Perforce que simplifica el proceso de migración. Listo en 3.0.

Nueva vista de "cambios pendientes" en la GUI (y en la shellext): ahora los checkouts + los cambiados (modificados fuera del control de plastic, por ejemplo sobrescribiendo un fichero sin más) + los privados (y potencialmente pendientes de añadir) se muestran juntos y se les puede hacer "checkin" a la vez. Mucho más cómodo que antes, especialmente para usuarios SVN.

Xmerge / Xdiff 2.0: la joya de la corona en 3.0. Hemos estado desarrollando esta tecnología durante mucho tiempo, y por fin ve la luz. ¿De qué va esto de "cross-merge" y "cross-diff"? Símplemente, de detectar código movido en las diferencias. Editas un fichero, mueves un trozo de código de sitio, lo modificas, y Plastic sigue sabiendo de dónde viene. Y lo mejor, que es capaz de hacerlo con los "merges" también. Suena pretencioso pero... ¡¡nadie más es capaz de hacer esto a día de hoy!! Merece la pena probarlo.

External data storage: una característica totalmente pensada para los equipos de desarrollo de videojuegos que trabajan con ficheros enormes. La idea es poder "extraer" revisiones de la base de datos del repositorio de modo que dejen de ocupar en el "servidor central" pero que todavía sigan siendo accesibles, ya sea bajo demanda (el usuario accede a esa revisión y Plastic le pide que meta un DVD con esos datos, vamos, un DVD o lo que sea) o centralizado (se monta un disco externo en el servidor y se ponen ahí los datos extraídos en lugar de en el repo principal). Útil cuando se manejan ficheros muuuuy grandes.

Annotate en la GUI: ahora el annotate (cm annotate or cm blame) ya no sólo es accesible en la línea de comandos (y en IntelliJ) sino también desde la herramienta gráfica.

SQLite backend: otra base de datos más a la lista! Hasta ahora un servidor de Plastic se podía configurar para trabajar contra Oracle, SQL Server, MySQL y Firebird, y a partir de ahora SQLite está también en la lista. Yo lo llevo usando desde hace 3 meses y va muy bien (tan rápido como un MySQL para uso individual), pero claro, está pensado no para servidores centrales (no admite acceso concurrente!) sino para montarte un servidor en un portátil y replicar.

Selector explorer: algo que también nos habían pedido 1 millón de veces: poder explorar selectores, ramas, etiquetas, sin tener que bajar el contenido. Sirve para experimentar con selectores y aprender mejor cómo funcionan.

Mejoras de rendimiento. 3.0 es al menos un 30% más rápido que 2.9 en situaciones de carga. ¿Qué quiere decir esto? Probamos Plastic con un servidor (un QuadCore con 4Gb de RAM, nada del otro mundo) y 100 máquinas cliente simulando usuarios a tope de carga (de hecho realmente la carga simulada es mucho mayor que la de un grupo de 100 desarrolladores, en nuestras pruebas generamos más carga en 20 minutos de test que un grupo de 150 programadores durante un día entero), y con esa configuración optimizamos Plastic y comparamos con otros sistemas, como por ejemplo Subversion. Publicaremos en las próximas semanas los números de Plastic vs SVN, pero os puedo adelantar que, literalmente, volamos mientras SVN se arrastra... y cuanta más carga, más rápidos nosotros y peor Subversion. También se aplica a operaciones individuales. Por ejemplo, un ciclo "add + ci" (añadir un workpace y hacer ci) es mucho más rápido ahora que con 3.0.

Detallaré cada una de las características en los próximos días, mientras tanto, ¡¡descargad 3.0 y probad todas las nuevas características!! :)

Agile Retrospectives (II): Fases

2010-06-07T14:00:00.001+02:00

En el artículo anterior presentábamos las generalidades de una reunión retrospectiva y algunos consejos. En esta ocasión presentaremos detalladamente las secciones de que debería constar un retrospective, que son:

Establecer el escenario.
Recoger datos y métricas.
Generar reflexiones y opiniones.
Decidir qué hacer.
Cerrar el retrospective.

Establecer el escenario

Introduce el encuentro, procura que todo el mundo diga sus imporesiones en una palabra o dos al comienzo. Sé breve, pero es importante hacer que todo el mundo hable desde el primer minuto, y la mejor manera de hacerlo es solicitando a cada uno una primera impresión muy breve.

Establece el tiempo que durará la reunión y los puntos a tratar. Describe una serie de objetivos o normas que identifican al equipo y que deben cumplirse durante la reunión. Ejemplo: "Todo el mundo debe participar".

Recoger datos y métricas

No sólo recoger datos, sino también compartirlo con el equipo. Esto aumenta la perspectiva de cada miembro, haciendo que expongan sus impresiones generales en lugar de sus impresiones personales. Facilita el que cada miembro comparta sus emociones con el resto acerca del último sprint. No preguntes directamente por sus emociones, sino pregunta indirectamente. Ejemplos: ¿qué día viniste a trabajar con más entusiasmo? ¿qué tarea te gustó más? ¿qué día viniste solamente por obligación? ¿qué tarea te gustó menos? Todo esto se convierte en una vía de escape controlada para el equipo, en lugar de retener sentimientos y explotar al final.

Generar reflexiones y opinones

Es el momento de pensar "¿por qué?" y pensar qué debería hacerse de forma diferente. Conduce a que el equipo piense en qué condiciones, interacciones y patrones contribuyeron al éxito. Investiga deficiencias, riesgos y malos resultados.

Decidir qué hacer

Escoge no más de dos puntos de mejora para el siguiente sprint y céntrate en cumplirlos. Demasiados puntos de mejora tienden a sobrecargar, estresar y que al final no se cumpla ninguno.

Planifica un descanso entre el retrospective y la reunión de planificación, para que la gente reflexione sobre qué y cómo planificar en base a lo decidido en el retrospective.

Cerrar el retrospective

Cierra adecuadamente la reunión. Resume conclusiones. Resume en una pizarra bien visible y a la vista de todos, los puntos de mejora adoptados. Éstos pertenecen al equipo, no al gestor. De este modo evitaremos el que cuando todo el mundo salga de la reunión se olvide de lo hablado hasta el siguiente sprint.

Haz un rápido retrospective del retrospective: qué fue bien durante la reunión y qué se puede mejorar para la siguiente.

Y en la siguiente entrega...

Actividades para realizar duante la reunión, cuyo objetivo es fomentar la participación de los asistentes, desentumedecer mentes adormiladas y fomentar la aparición de ideas. Nos leemos en el siguiente, entonces.

Referencias:

Agile Retrospectives – Making good teams great

Esther Derby, Diana Larsen

Agile Retrospectives: cómo mejorar

2010-06-07T13:59:00.000+02:00

En una pequeña serie de artículos resumiré lo que encontré recientemente en el libro que abajo se referencia referente a cómo mejorar las reuniones retrospectivas (qué mal suena; no, no estoy hablando de Retrospector ni nada relacionado con La Hora Chanante).

¿Qué es un 'retrospective'?

Una retrospección en la vida es pararse por un momento, mirar hacia atrás y reflexionar sobre el camino trazado hasta la fecha, evaluando las cosas buenas y las malas, y aprendiendo de todo ello para ser mejor persona.

Esto, que muchos seres humanos que andan sueltos por ahí deberían hacer a menudo, en las metodologías de desarrollo ágil de software se llama "retrospective" y en un modelo de desarrollo iterativo viene muy bien para evaluar cada una de esas iteraciones que se realizan. En nuestro caso particular orientaremos el discurso hacia SCRUM, quizá la metodología ágil más conocida y extendida, junto con eXtreme Programming.

Fases de un 'retrospective'

Una buena reunión retrospectiva debería constar de las siguientes fases:

Establecer el escenario.
Recoger datos y métricas.
Generar reflexiones y opiniones.
Decidir qué hacer.
Cerrar el retrospective.

Estas fases, no parecen nada del otro mundo y muchos equipos las llevan a cabo, en mayor o menor medida. ¿Por qué aun así no hacen buenos retrospectives? Bueno, quizá el problema está en el cómo y no en el qué.

¿Quién dirige un 'retrospective'?

Un retrospective puede estar dirigido por el gestor del equipo o por cualquier miembro del mismo, o incluso ir variando en cada ocasión. Quien dirige la reunión deberá mantenerse lo más al margen posible, porque el poder subyacente que posee quien dirige la reunión puede coartar a los demás miembros a participar. Esto es especialmente apblicable al gestor, que en cualquier caso se mantendrá lo más al margen posible de la discusión, debido a que su estátus puede influir en las opiniones del equipo y romper la dinámica del grupo.

Es importante identificar qué parámetros se han de analizar en un retrospective. Algunos buenos ejemplos:

Buscar modos de mejorar las prácticas.
Descubrir qué se hizo bien.
Entender las razones subyacentes por las que no se cumplieron los objetivos.
Buscar modos de mejorar la responsabilidad de cara a los clientes.
Reconstruir relaciones maltrechas.
...

Y para terminar esta sección, dos máximas que deben cumplirse durante una reunión retrospectiva:

Evitar culpabilizar a sujetos por el incumplimiento de un objetivo.
Facilitar el que todo el mundo hable.

¿Cuánto debe durar un retrospective?

Depende.

De la duración del sprint, de la complejidad de la tecnología que se maneja en dicho sprint, del tamaño del equipo y del nivel de conflictos y controversias en las opiniones de los miembros. Como guía: cada semana de sprint, una hora de reunión retrospectiva.

Acortar el tiempo de la reunión es hacer trampa y engañarse uno mismo; sin embargo, si los objetivos se cumplieron se puede acortar la reunión.

Por otro lado, los retrospectives deben prepararse previamente. El equipo debe entrar en la sala de reuniones con algo mínimamente preparado, un adelanto de lo que se va a hablar.

¿Cómo preparar retrospectives?

El responsable debe responder a las siguientes preguntas:

¿Cuál es el objetivo de la reunión?
¿Quién atenderá?
¿Cuánto durará?
¿Dónde se celebrará?
¿Cómo se organizará la sala?

¿Como hacer que el equipo prepare la reunión?

Puede enviarse un pequeño cuestionario por correo electrónico a todas las personas que van a asistir a la reunión antes de hacer el retrospective. De este modo se forzará a que el equipo se tome unos minutos en reflexionar sobre el sprint. Tras recibir las respuestas, que se tratarán anónimamente, pueden leerse los resultados en voz alta durante el retrospective, de manera que sirva como resumen de las impresiones generales del grupo.

Otra opción es solicitar un breve resumen de las impresiones del sprint.

¿Y después de la reunión?

Asigna cada acción a realizar en el siguiente sprint a un responsable. Muchos retrospectives fracasan porque, a pesar de que se aportan buenas ideas, éstas quedan en el aire y se olvidan para el siguiente sprint. Asigna responsables y haz que el equipo colabore en el cumplimiento de dichas acciones.

Y en la próxima entrega...

He dado un rodeo a propósito para no explicar detalladamente las fases de una reunión retrospectiva. Mi objetivo aquí ha sido el de sentar las bases, dar unos primeros consejos y establecer algunas ideas. En la próxima entrega explicaré detalladamente en qué consiste cada fase.

Y en siguientes entregas explicaremos una serie de actividades que pueden realizarse durante la reunión retrospectiva y cuyo objetivo primordial es fomentar la participación. Fuera aparte de las ideas que surjan, de las decisiones tomadas y todo lo demás. Lo principal es hacer que todo el mundo participe. Lo demás vendrá sólo.

Referencias:

Agile Retrospectives - Making good teams great

Esther Derby, Diana Larsen

¿Es tu software como esto?

2010-03-26T12:33:00.004+01:00

He visto el link a la imagen en reddit.com, qué os parece??

Demasiada memoria gracias al Garbage Collector

2010-03-24T16:03:00.012+01:00

Parece que está claro que programar en algo como C#/.NET (incluso C#/Mono) es mucho más rápido que intentarlo con C/C++: unas librerías potentes, un lenguaje sencillo y (lo que todos dicen) no más mallocs ni frees.

(Nota: hace un par de semanas en Game Developers Conference 2010 había una mesa rendonda en la que precisamente hablaban de las limitaciones de C++ (su complejidad básicamente) para el desarrollo de videojuegos y cómo les gustaría tener GarbageCollector… aunque al final todo el mundo coincidía en que les gustaba C++ a pesar de todo…)

Bien, volviendo a .NET: Garbage Collector, uno de los elementos claves de framework (y lo mismo se puede decir en Java) proporciona muchas ventajas: escribes y listo, te olvidas de líos. Pero… ¿es todo positivo? En Java estamos acostumbrados a ver aplicaciones consumiendo cantidades astronómicas de memoria (incluso hay IDEs como IntelliJ con un botoncito para llamar al GC, ni más ni menos) y lo mismo puede ocurrir con .NET. En muchas ocasiones no es un problema sino un tema estético: como el GC sabe que hay memoria de sobra disponible, y para mejorar el rendimiento, no recolecta la basura, así que el proceso sigue creciendo.

Pero para mí el mayor problema no es ese sino la sensación que va creando en todos los programadores de que la memoria es gratis. ¿Qué quiero decir con esto? Pues que acabas creando objetos y objetos y objetos nuevos porque es rápido y sencillo… aunque puedes estar estresando al GC más de la cuenta.

Un ejemplo práctico: servidor y blobs

Un ejemplo claro de cómo me encontré con el problema y cómo creo que en C jamás hubiera ocurrido.

Tengo un proceso servidor en .NET que procesa peticiones de clientes realizadas a través de la red, lee datos (blobs) de una base de datos y los devuelve al cliente. Muy sencillo.

Bien, cuando el nivel de carga del servidor no es muy alto todo funciona perfectamente: el servidor lee objetos, los devuelve, libera memoria de vez en cuando… todo perfecto.

Pero, ¿qué ocurre cuando ponemos unos cuantos cientos de clientes contra el mismo servidor?

Pues que la memoria del servidor comienza a crecer muchísimo, vemos como el tiempo haciendo GC aumenta también (se puede ver con el Process Explorer de SysInternals, http://technet.microsoft.com/es-es/sysinternals/bb896653.aspx, por ejemplo, donde te da una medida del tiempo que tu proceso (.Net 2 o superior) está gastando en GC).

¿Por qué ocurre esto?

Lo que yo estaba haciendo para procesar la petición era algo como esto (tipo pseudocódigo):
public byte[] GetData(long dataId)
{
byte[] result = new
byte[GetDataLen(dataId)];
ReadData(dataId, result);
return result;
}

¿Veis el problema?

Ahora me parece totalmente evidente pero la verdad es que tardé un rato en darme cuenta porque con el profiler de memoria (usaba la herramienta de RedGate Ants, http://www.red-gate.com/products/ants_memory_profiler) no detectaba nada de nada, parecía que todo estaba bien.

Objetos en tránsito

¿Cómo funciona el servidor? Cada método GetData se va a invocar en un thread (realmente no creando un thread nuevo, que parece un pecado, sino usando un thread pool) diferente, hace su trabajo y termina.

Entonces, ¿por qué tanta memoria? El siguiente gráfico lo explica claramente:

El método GetData está funcionando bien pero lo está haciendo en "modo .NET", es decir, lo he escrito como si la memoria fuera gratis.

Cuando se acumulan peticiones la cantidad de memoria inútil reservada será enorme dependiendo de cuántas llamadas se estén procesando (de la carga del servidor). Viendo el gráfico está claro que la memoria que se reservó para procesar la primera petición en el instante 0 en el primer thread no vale para nada ya en el instante 2 y sin embargo sigue ocupando sitio en el proceso…

Y este es precisamente el problema: los objetos en tránsito, objetos que todavía no se han liberado pero que siguen ocupando sitio.

Pensamiento tipo C

Esto nunca le hubiera pasado a un desarrollador C/C++ por dos motivos: primero porque un free es un free de verdad y liberaría la memoria inmediatamente. Segundo porque estando acostumbrado a una vida mucho más dura, trataría de evitar tanto malloc/free (o new/dispose).

¿Qué pasa si creamos un buffer pool con unos cuantos buffers pre-creados que reutilizamos en cada petición? El código pasaría a ser algo como esto:

public byte[] GetData(long dataId)
{
byte[] result = GetBuffer(GetDataLen(dataId));
ReadData(dataId, result);
return result;
}

public void ProcessRequest(long dataId)
{
byte[] result = GetData(dataId);
ReturnData(result);
ReleaseBuffer(result);
}

Varios puntos a tener en cuenta:

Para simplificar algo como esto ayuda mucho si los datos son de tamaño fijo, o al menos tienen un tamaño máximo. En mi caso un bloque de datos nunca era mayor de 4Mb, por lo que es muy sencillo de manejar el buffer pool porque todos los buffers serán del mismo tamaño (el máximo).

Si todos los buffers son del mismo tamaño habrá que manejar cuál es el tamaño usado de verdad, es decir, si estás leyendo 1024bytes en un buffer de 4Mb, luego no envíes 4Mb por la red!!! Envía sólo lo que estás usando. Esto posiblemente requerirá un código del tipo:
public void ProcessRequest(long dataId)
{
byte[] result = GetBuffer();
try{
int size = ReadData(dataId, result);
ReturnData(size, result);
}
finally
{
ReleaseBuffer(result);
}
}

Que por otro lado es mucho más limpio.

Hay que acordarse de liberar el buffer (tipo C) que realmente no hace nada más que devolverlo al buffer pool. Si el código de obtención y liberación del buffer está en el mismo método y con un try/finally, mucho mejor: más fácil de leer y menos propenso a fallos (no me gusta cuando el código de obtener y liberar un recurso o memoria, o lo que sea, no está en el mismo bloque).

Lógicamente hay que implementar el buffer pool de forma que:

Sincronice el acceso de varios threads

Se pueda limitar el número máximo de buffers: de este modo se puede controlar cuál va a ser el uso de memoria de nuestro servidor: no ocurrirá NUNCA que se descontrole como pasaba antes, el consumo será plano, el GC no tendrá trabajo y todo será más rápido. ¿Cómo limitarlo? Por ejemplo con un sencillo semáforo que bloquee en la llamada GetBuffer hasta que queden buffers libres. NOTA IMPORTANTE! En caso de usar un semáforo es muy importante considerar el riesgo de deadlocks si empezamos a usar múltiples pools (después del primero vendrán más) y los threads intentan acceder a ellos sin un orden muy estricto (la vieja regla: reserva SIEMPRE en el mismo orden y nunca tendrás deadlocks, reserva en orden diferente y espera el desastre).

Remoting: más complicado

En mi caso real (no descubrí esto en un programa de 5 líneas con un GetData, desgraciadamente) el servidor no estaba usando sockets directamente sino .NET Remoting, así que en la película entraban más complicaciones como la serialización de objetos y las múltiples copias que Remoting hace hasta llegar a la capa de red. Para evitarlo no quedó más remedio que escribir un custom tcp channel capaz de manejar el buffer pool reservado en la capa de aplicación y liberarlo justo después de poner los datos en la red, y evitando también la lenta serialización estándar de .Net… pero esto ya es otra historia para otro día.

Plastic SCM 2.9 ya está aquí!!

2010-03-02T00:09:00.004+01:00

Plastic SCM llega a su versión 2.9 y está listo para descargarse desde nuestra web: www.plasticscm.com.

La nueva versión viene cargada con un buen número de nuevas características y también es mucho más rápida, especialmente bajo carga.

Estas son algunas de las nuevas características:

Soporte de Oracle: hemos añadido Oracle a la lista de backends con los que PLlastic puede funcionar. Hasta ahora soportábamos MySql, SQL Server y Firebird (tanto servidor como embebido). Nos han pedido Oracle varias veces, especialmente desde grandes equipos así que por fin está disponible. Se trata posíblemente del gestor de bases de datos más conocido tanto por rendimiento como estabilidad y escalabilidad y puede usarse con servidores Plastic en Windows, Linux y MacOS X.

Integración continua con Pulse: hemos desarrollado un plugin para el producto de integración continua de Zutubi. Hasta ahora ya nos integrábamos con productos como CruiseControl y FinalBuilder, pero Pulse es quizá mi favorito y estamos trabajando en ampliar la integración para que soporte patrones como rama por tarea, y así poder implantarlo internamente. Otros sistemas, como Hudson, también funcionan con Plastic.

Servidor proxy: otra de las características más esperadas. Ahora se puede configurar un servidor proxy de Plastic para reducir el uso de red mientras se trabaja conectado a un servidor central. El servidor proxy es muy sencillo: símplemente descarga datos bajo demanda que le solicitan los clientes y los cachea para el siguiente uso. Con esto se ahorra uso de red lo que puede ser crítico cuando se acceede al servidor a través de VPN o conexiones lentas. Nota: Plastic puede funcionar en modo distribuido pero algunas empresas prefieren llevar ciertos proyectos de forma centralizada, y es ahí donde el proxy server juega un papel importante.

Sparse tree y cloaking: que se traduce por algo como árboles parciales y evitar que ciertos ficheros se actualicen. Mediante un nuevo fichero de configuración llamado cloaked.conf es posible definir reglas para indicar qué ficheros se pueden descargar y qué ficheros no, es algo complementario a lo que ya se puede hacer con los selectores, pero permite funcionalidades diferentes. Por ejemplo, se puede descargar un árbol de directorios y luego indicar que ese árbol está cloaked lo que quiere decir que no se volverá a actualizar. Es útil para mejorar el rendimiento cuando se trabaja con proyectos muy grandes. Sólo para usuarios avanzados.

Uso de memoria en la replicación. El uso de memoria en todo el proceso de replicación se ha reducido considerablemente, haciendo que el proceso sea mucho más rápido y eficiente que antes. Ahora se puede replicar un repositorio completo sin que el servidor se entere a nivel de uso de memoria!

¡Eliminación del workspace server! Sí, como leeéis, el hemos eliminado el componente servidor de workspaces del mapa. Bueno, de hecho no se ha ido sino que se ha trasladado a cada cliente, de modo que el rendimiento aumenta de forma espectacular. ¿Qué significa esto? Echa un vistazo a un nuevo workspace y verás que contiene un directorio (oculto) denominado .plastic. Contiene información sobre el workspace como el selector y el árbol de la copia de trabajo. Toda esa información solía estar en el servidor y ahora se ha movido al cliente, lo que supone que se reduce significativamente el uso de red, lo que podrán apreciar especialmente los usuarios de redes VPN (en LAN la velocidad ya era tan alta que no se apreciará mucha diferencia). Nota importante: cuando te actualices de Plastic 2.8 a 2.9 verás, en el primer arranque, un diálogo como el siguiente que indicará el progreso de la conversión de workspaces.

Workspaces compartidos: tras las modificaciones realizadas en los workspaces ahora se pueden compartir: se puede ubicar un espacio de trabajo en un directorio compartido (por Samba o por NFS, por ejemplo) de forma que más de un usuario pueda acceder a él e incluso actualizarlo y acceder a información de Plastic desde varias ubicaciones. Antes se podía hacer registrando el workspace en diferentes máquinas, pero se podía llegar fácilmente a condiciones en las que el sistema no se comportase bien porque para Plastic eran workspaces diferentes. Lógicamente es una característica para usar con cuidado: es útil para usarlo con sistemas de compilación, o de paso a producción, no para trabajar a diario ya que el objetivo de un control de versiones es precísamente coordinar diferentes copias de trabajo, ¡¡no trabajar sobre una misma!!

Exploración de changesets: una de las nuevas características más potentes. Ahora se puede caminar por las ramas cambio a cambio (changeset a changeset) leyendo la historia que cuentan. Escribiré otro post sobre esto pero para hacer una breve introducción: en tu propia rama de tarea eres libre de hacer tantos checkins como quieras, pero todos esos checkins deberían de tener un significado, ir describiendo cambios uno a uno, de modo que todos tengan una lógica. Supongamos que vamos a hacer un refactor importante, de muchos ficheros, si comparas el contenido de la rama una vez que has terminado verás tantísimos cambios que será difícil de entender lo que has hecho, sin embargo si has podido descomponer el refactor en pequeñas operaciones y has ido haciendo checkin de cada una de ellas, se podrá revisar posteriormente los cambios que has hecho, como si fuera ver una repetición de la jugada. El mecanismo de commit no es nuevo, por supuesto, pero la herramienta de recorrido de cambios permite que se usen para describir cambios casi contando cómo lo has ido haciendo, dejando registrado no sólo lo que haces sino cómo lo haces, con todas las aplicaciones que eso tiene.

Mejoras en el branch explorer: siempre en evolución, hemos añadido la capacidad de búsqueda que permite ir navegando las ramas que cumplan el filtro, lo que es mucho más útil que antes. También la posibilidad de hacer clic sobre los link de merge y ver de dónde vienen y hacia dónde van. Y por último el editor de visibilidad que tantas veces nos han pedido y que permite ocultar ramas que no interese ver.

Y estas son todas las funcionalidades importantes en 2.9 junto con un buen número de correcciones.

Y por supuesto mejoras de rendimiento: probamos Plastic cada semana en un cluster con 100 nodos y bajo esa carga 2.9 es un 30% más rápida que 2.8. Recordad que Plastic 2.8 era ya 10 veces más rápido que SVN... así que calculad 2.9!!

Y por supuesto a pesar de seguir creciendo Plastic es todavía fácil de usar y de instalar. Echad un vistazo al siguiente vídeo en el que se configura un servidor en menos de 45 segundos!! Y después se hace una importación inicial de código (algo que es muy común en cualquier evaluacion) durante el siguiente minuto!

Tutorial sobre selectores (II)

2009-04-16T10:39:00.004+02:00

Cambio de selector en un Espacio de trabajo.
Cambiar el selector de un espacio de trabajo en PlasticSCM es sencillo. En primer lugar debemos activar el espacio de trabajo cuyo selector queremos editar. Esto es lógico, pues no tendría mucho sentido cambiar el selector de un espacio de trabajo que no se va a utilizar. Además, si posteriormente activáramos tal espacio de trabajo sin mirar su selector podríamos estar realizando acciones que no deberíamos con la consiguiente pérdida de trabajo.

Para activar un espacio de trabajo, haga clic sobre la vista Workspaces, situada en la esquina superior derecha de la pantalla. Esta vista muestra la lista de espacios de trabajo existentes. A continuación haga clic derecho sobre el espacio de trabajo a activar y seleccione “Activar espacio de trabajo…”, tras lo cual se le pedirá confirmar tal acción y se descargará el espacio de trabajo.

Opción de cambiar selector. Haga clic para ver la imagen más grande.

A continuación ya podemos cambiar el selector del espacio de trabajo activo. Para ello, haga clic derecho sobre el espacio de trabajo activo en la lista y seleccione la opción “Establecer selector…”, tras lo cual se abrirá la ventana del editor del selector en la cual podrá teclear las nuevas reglas a aplicar. Una vez introducidas tales reglas, el sistema tratará de aplicarlas, actualizando el espacio de trabajo con lo que hay en el repositorio según las reglas, lo cual demorará unos segundos. Si todo ha ido bien la barra de progreso desaparecerá y podrá constatar los cambios aplicados en la esquina superior derecha de la pantalla, donde se indica la rama y etiqueta seleccionadas actualmente, así como en la lista de ítems descargados. Si la regla especificada contiene algún error se mostrará una ventana con los errores encontrados.

Un error bastante común, aparte de los típicos errores de sintaxis es tratar de descargar una etiqueta no aplicada. Vigile que aplica sus etiquetas (no solamente creándolas, sino aplicándolas a una versión particular) para que el selector pueda aplicar las reglas correctamente.

Tutorial sobre selectores (I)

2009-04-08T09:56:00.003+02:00

QUÉ ES UN SELECTOR. NECESIDAD DE LOS SELECTORES.

Un selector es una herramienta sintáctico-descriptiva que permite al usuario indicar qué ficheros desea obtener del repositorio en su espacio de trabajo. La necesidad de tal herramienta se debe a que no siempre desearemos obtener la última versión existente, sino que en ocasiones desearemos crear espacios de trabajo locales con un release pasado, una versión etiquetada de una determinada forma o el contenido de una rama en particular, con el objetivo de realizar una revisión del código o reparar un error.
Mediante el uso de selectores, por tanto, el usuario puede elegir sobre qué ítems del repositorio desea trabajar.

CÓMO LO IMPLEMENTA PLASTICSCM.

Un selector es una especificación de qué revisiones de qué ítems serán descargados al espacio de trabajo local. Como consecuencia de la necesidad de un selector, es necesario también indicar en qué rama se crearán las desprotecciones de las nuevas revisiones creadas fruto de los cambios realizados sobre tales ítems.

El selector más común es el que se tiene por defecto al crear un espacio de trabajo nuevo, que tiene este aspecto:

Tal especificación indica que se tomarán ítems del repositorio default, del cual se descargará todo aquello que esté directamente bajo el directorio raíz, en la rama principal. Las desprotecciones y cambios en los ítems descargados irán a parar a la propia rama principal.

En lugar de descargar una rama podemos indicar que deseamos descargar una etiqueta, un grupo de cambios (changeset) o una revisión de un ítem determinada. Lo que siempre hay que tener en cuenta es que debemos indicar una rama que almacenará los cambios realizados, es decir, hay que indicar una rama de checkout. La sintaxis para la especificación de un selector es la siguiente (haga clic sobre la imagen para verla más grande):

Podemos indicar un número de revisión concreta o bien la primera (FIRST) o la última (LAST) disponible; indicar un changeset determinado, una rama concreta o una etiqueta marcada. Podemos descargar directorios recursivamente o no, según sea nuestra intención. La sintaxis admite algunas expresiones regulares, con lo cual podemos especificar ficheros de una determinada extensión, de un determinado patrón de caracteres en el nombre, etc. Ejemplo:

repository "codice"

path "/01nerva/doc/*.doc"

lb "BL034"

path "/01nerva/doc" norecursive

lb "BL034"

path "/01nerva" norecursive

lb "BL034"

path "/" norecursive

br "/main"

Este selector descargaría del repositorio codice, utilizando la ruta /01nerva/doc/ todos los ficheros con extensión .doc etiquetados con BL034, además de todos los ficheros del directorio padre, del directorio abuelo y del directorio raíz que estén en la rama principal etiquetados de la misma forma. Conviene fijarse en que solamente se descargará el camino que va desde la raíz hasta el directorio de documentación, y que si tal direcotorio doc tuviera directorios hermanos (en el mismo nivel), éstos no serían descargados. Esto se debe a la opción norecursive utilizada en la especificación de path de los directorios de nivel superior.

Tutorial sobre branching (III)

2009-04-01T09:44:00.006+02:00

En esta última parte del tutorial explicaremos cómo manejar ramas con Plastic SCM.

Crear una rama en Plastic.

Una vez arrancada la aplicación, haremos clic sobre el botón “Explorador de Ramas”, que cargará el gráfico descriptivo del estado del desarrollo actual. Una vez cargado el gráfico haremos clic derecho sobre la rama principal y seleccionaremos la opción “Crear rama hija...”.

Aparece un cuadro de diálogo donde indicaremos el nombre de la rama, unos comentarios (opcionalmente), e indicaremos el punto de creación de la nueva rama desde la rama principal: si va a partir de una etiqueta o conjunto de cambios concretos, o bien si va a partir del último punto que actualmente existe en la rama principal. Finalmente pulsaremos sobre “Aceptar”.

Pulsando sobre el botón “Actualizar” en el “Explorador de Ramas” podremos visualizar ahora la nueva rama creada.

Otra forma de crear nuevas ramas es desde la vista “Ramas”. Hacemos clic derecho sobre una de las ramas listadas y a continuación sobre la opción “Crear rama hija...”. El proceso a partir de aquí es idéntico a lo explicado antes.

Unir ramas.

Una vez se han realizado los cambios deseados en la rama, podemos actualizar dichos cambios en la rama principal. Para ello realizaremos una operación de merge entre dicha rama y la rama principal. Esta operación se lleva a cabo de la siguiente manera:

En la vista “Explorador de Ramas”, hacemos clic derecho sobre la rama principal y seleccionamos la opción “Cambiar espacio de trabajo a esta rama...” y a continuación confirmamos el cambio pulsando sobre “Sí” en el cuadro de diálogo que aparece. Esto se hace porque el destino del merge es la rama principal.

A continuación hacemos clic derecho nuevamente sobre la rama principal y seleccionamos la opción “Merge desde esta rama...”; aparece un cuadro de diálogo donde indicaremos la rama o etiqueta con la que se unirá la principal pulsando sobre el botón “Cambiar...” adecuado. Una vez seleccionada la etiqueta o rama con la cual se desea unir (eligiendo la deseada en la lista de la ventana que aparece y haciendo clic sobre “Aceptar”) pulsaremos sobre “Buscar merges”. Se nos sugerirán los posibles merges que habría que realizar para unir las ramas. Seleccionaremos uno de ellos y pulsaremos sobre “Merge” o bien elegiremos la opción “Merge todo”. Si no hay conflictos el programa resolverá los merges mostrando una ventana de progreso y al final un mensaje de éxito en la operación. Podremos cerrar la ventana. Ya hemos añadido los cambios de la rama secundaria a la rama principal.

Unir ramas con conflictos.

¿Qué ocurre si al unir las ramas existen conflictos entre algunos ficheros? En este caso se cargará la herramienta de diferencias, que nos mostrará los conflictos existentes entre los ficheros. Se mostrará en la parte superior de la pantalla el contenido del archivo origen del merge, el del destino del merge y la copia antigua del destino. En la parte inferior se mostrará cómo quedaría el resultado. Mediante un código de colores podemos conocer qué texto pertenece a cada uno de los componentes del merge. Este panel inferior se puede editar a mano, tecleando sobre el mismo. Además podemos marcar o desmarcar uno de los componentes del merge pulsando en el texto superior de cada panel para hacer que los cambios introducidos en ese componente se reproduzcan en el resultado o no. Una vez hayamos seleccionado el aspecto final del fichero, pulsaremos sobre el botón “Guardar”, situado en la esquina superior izquierda de la pantalla. La herramienta de diferencias nos llevará al siguiente conflicto, y así hasta que no haya más conflictos. Podemos navegar entre los conflictos utilizando los botones de flecha que aparecen en la parte superior de la pantalla de diferencias y que asemejan a un reproductor de música.

Nota: En cualquier caso, una vez completada la unión entre ambas ramas, tanto los ítems que han sufrido un merge automático como los que han sufrido un merge manual están desprotegidos para que el usuario pueda constatar los resultados del merge y comprobar si está conforme. Para ver estos elementos, puede pulsar sobre la vista “Checkouts”. Puede abrir tales elementos haciendo doble clic sobre cada ítem de la lista. Una vez esté conforme con el resultado puede proceder a proteger tales ficheros. Para ello, seleccione uno o varios de los elementos, a continuación haga clic derecho y seleccione “Check in”, o bien pulse Ctrl+I.

Otras opciones.

Además de lo anteriormente expuesto, haciendo clic derecho en una de las ramas listadas en la vista “Ramas” o sobre una de las ramas representadas en el gráfico del “Explorador de Ramas”, podemos visualizar el contenido en ítems de una rama, “Cambiar el espacio de trabajo a esta rama” para activarla y trabajar con ella, podremos realizar diversas opciones de replicación de ramas, renombrar y borrar una rama, comparar el contenido de una rama con el de otra rama o con una etiqueta, crear una rama de primer nivel (/main), ver las propiedades de la rama o cambiar sus permisos.

Tutorial sobre branching (II)

2009-03-26T09:44:00.004+01:00

Cómo resuelve el problema PlasticSCM.

¿Qué herramientas proporcionan un mecanismo de branching potente complementado con un mecanismo de merging eficaz?

PlasticSCM implementa un mecanismo de branching que permite tener abiertas un gran número de ramas sin que el sistema se vea afectado en rendimiento. Además la gestión de tales ramas es bien sencillo mediante sus representaciones gráficas en dos y tres dimensiones.

El rendimiento del sistema de branching es muy alto en PlasticSCM debido a que no implementa las ramas como lo hacen otros Sistemas de Configuración Software. PlasticSCM únicamente enlaza de forma lógica la nueva rama a la rama origen de la que parte, de manera que en el momento de creación de la rama ésta se encuentra vacía. A continuación va añadiendo las modificaciones de los ficheros de la rama origen que van siendo desprotegidos y modificados en la rama creada. Con ello el espacio ocupado, tanto en disco como en memoria es mucho menor, ya que no se replica todo el contenido de la rama original en la rama secundaria.

PlasticSCM, además, implementa un eficaz sistema de merging que permite unir ramas, etiquetas, revisiones, conjuntos de cambios, etc. de la forma más automática y transparente posible para el usuario, y en aquellos casos en los que existen conflictos en las modificaciones de los mismos ficheros proporciona una sencilla herramienta de diferencias que permitirá seleccionar y editar qué modificaciones se quedarán en el resultado.

Tutorial sobre branching (I)

2009-03-17T09:55:00.003+01:00

A lo largo de 3 entregas veremos un pequeño tutorial sobre branching. En la primera entrega enunciaremos algunos conceptos y la necesidad de branching; en la segunda, cómo resuelve PlasticSCM el problema del branching, y en una tercera y última entrega veremos qué pasos hay que seguir en PlasticSCM para trabajar con ramas.

Introducción y necesidad de branching.

Cuando en el desarrollo de un proyecto software intervienen varias personas o se desea realizar un desarrollo iterativo de entrega incremental, en el cual se van publicando sucesivos releases del producto, se hace necesario un modelo de construcción estructurado, que se adapte a nuestra forma de trabajar y que facilite un desarrollo paralelo en la medida de lo posible.

Pero, ¿qué es realmente un desarrollo paralelo? Un desarrollo paralelo no es aquél en el que un programador espera a que otro acabe para editar un mismo fichero, sino aquél que permite que los programadores trabajen de forma independiente unos de otros, sin tener que preocuparse por si alguien estará trabajando sobre los mismos ficheros que yo.

Este modelo de trabajo es realmente productivo, pues permite aprovechar todo el potencial de cada desarrollador individual pero trabajando en colectivo. Claro, que no deja de ser una propuesta bastante ambiciosa. ¿Cómo lograr esto?

Planteemos otro problema: en un proyecto que utiliza desarrollo iterativo con entrega incremental, ¿cómo podemos organizar los sucesivos releases sin interferir unos con otros?

La solución a estos y otros problemas pasa por el branching, que consiste en crear distintas ramas de desarrollo, distintos flujos de progreso. Antes de entrar en materia, es conveniente aclarar que una rama es una herramienta, no una solución como tal, y como toda herramienta debe ser utilizada con responsabilidad y debe estar sustentada por una política de uso como base que permita aprovechar su potencial. Es decir: hay que decidir cuándo se crea una rama, cuándo se une tal rama a la rama principal, qué contiene la rama, etc.

También es necesario indicar que un mecanismo de branching tiene poca utilidad sin un mecanismo de merging (unión o reunión de distintas ramas) potente. Si no podemos unir las ramas secundarias a la rama principal de forma potente y a poder ser, sencilla y automatizada, de poco nos sirve poder ramificar.

¿Cómo resuelve el branching los anteriores problemas planteados? Para el primero, la solución pasa por crear una rama para cada tarea, o bien una rama para cada programador. De este modo cada programador trabajará en una rama independiente, en un espacio de trabajo independiente y no interferirá su trabajo con el de los demás, salvo en el momento de reunir los cambios con los del resto mediante una operación de merge. El segundo problema se puede resolver creando una rama para el release. Las pruebas y modificaciones que se realicen sobre ese release se realizarán sobre la rama secundaria creada a tal efecto, mientras que el desarrollo normal del proyecto puede continuar en la rama principal (posiblemente creando nuevas ramas por tarea o por programador), con lo cual el desarrollo no queda parado.

4 reglas para tu proceso de control de versiones

2008-08-20T09:46:00.003+02:00

Al principio todo era plano.

Pero ahora, ¡afortunadamente!, ya no es así...

Antecedentes
Vale, ¿por qué estoy escribiendo esto? Esta semana tuve la oportunidad de ver dos estupendas presentaciones de OSCON 2008:

La primera es de Mark Shuttleworth (Canonical, Ubuntu), titulada Más allá del desarrollo ágil: Posibilitar la Siguiente Generación de Métodos de Desarrollo de Software, y que trata sobre diversos temas muy interesantes tales como Lean Software Development. Podéis ver una presentación aqui, merece la pena.

La que realmente me gustó fué la diapositiva 17 en la que dice:

Branching and Merging
  Keep trunk pristine,
    Keep features flowing,
      Release on demand.

Que yo traduzco por:

Ramificación e integración
  Mantener la línea principal impoluta,
    Mantener la potencia de la herramienta en uso,
      Crear versiones bajo demanda.

Y la diapositiva 20 dónde menciona:

Pre-Commit Testing
  I see you knocking
    but you can't come in.

Que viene a ser:

Probar antes de realizar commit
  Veo que estás llamando
    pero no puedes entrar.

Como veis se centran en un punto crítico que es pasar todo el juego de tests antes de hacer commit, algo que puede sonar opuesto a la integración continua, pero que en realidad es una evolución del modelo.

También me gustó Code Reviews for Fun and Profit de Alex Martelli (Google) que se puede encontrar aquí .

Menciona lo siguiente en la diapositiva 26:

idealmente, la CR (code review) debería de tener lugar ANTES
del commit/inclusión de cambios en la
base de código
-- mantener la línea principal/inteligente/consejo de calidad

Esto también parece interesante, ¿no?

E incide sobre el mismo tema: revisar, probar, comprobar que no se rompe nada antes de hacer commit a la línea principal.

Y de todo esto se me ocurrió este post (que primero publiqué en inglés)

Las reglas

Vale, vamos a intentar localizar las principales reglas para conseguir el mejor control de versiones posible en la era post-agile:

Regla 1: Mantener la rama principal incorrupta. ¡La rama principal es tu proyecto! No la uses como un trastero (lleno de cosas que no sirven) para dejar todos los cambios y nuevas características. ¡Utiliza las ramas para eso! (Ya, ya lo oigo: "acabaremos con miles de ramas!!", claaaro, ¡y eso no es un problema! Usa un control de versiones adecuado! :-P)

Regla 2: Aislar cambios en ramas. Es una consequencia de la Regla #1. Guarda cada cambio o característica nueva en su propia rama. Ayudará a mantener la rama principal limpia, y te dará toda la potencia del desarrollo paralelo real. También es muy bueno para cambiar de tarea y hacer un seguimiento de los cambios intermedios.

Nota: Asocia tu rama con una con una tarea en tu herramienta de control de tareas (Bugzilla, Mantis, Jira ...) para poder tener el ciclo completo.

Regla 3: Guarda los cambios con cierta frecuencia, con más de la que lo haces ahora. Si desarrollas en la línea principal no harás commt cada 5 minutos, los cambios suelen tardar más en realizarse. Si tienes tu propia rama para la tarea puedes hacer commit tantas veces como quieras (¡aunque no compile!)... y luego tendrás un historial privado de los cambios.

Regla 4: Revisar los cambios antes de incluirlos en la línea principal. En el desarrollo en la rama principal (y en integración continua) se realizan las pruebas de tests después de que se hayan integrado los cambios. ¡No lo hagas! Sería demasiado tarde, el código ya está roto. Saca el máximo partido a tu herramienta de SCM, revisa los cambios antes de integrarlos.

La buena noticia es que hay herramientas que soportan este modelo, tanto en el ámbito comercial como en herramientas de código libre: plastic, accurev, git (bazaar?)...

La mala noticia es que algunas de las herramientas más utilizadas no soportan este modelo.

Llega una nueva era... ¡preparate!

Herramienta de Xmerge para gestionar refactors

2008-08-14T13:27:00.009+02:00

Si has leido este blog anteriormente, probablemente te habrás dado cuenta de que de vez en cuando hablamos de gestión de ramas y de integraciones :-P

Pues hoy vamos a introducir la última idea que hemos tenido: el Xmerge (integración cruzada o cross-merging).

¿Y qué es la integración cruzada? Explicado de manera simple: es tan sólo una herramienta que ayuda a los desarrolladores a integrar el código que se ha movido y modificado en paralelo. Esto pasa muy a menudo al hacer un refactor del código, ¿no?

Vamos a verlo con un ejemplo: supongamos que tenemos un fichero inicial como el siguiente:

Ahora dos desarrolladores comienzan a hacer cambios en paralelo en este fichero (lo cual es una buena idea, para que no tengan que estar esperando el uno a que termine el otro... :-P):

El primer desarrollador hace sus cambios y el segundo mueve el código.

¿Qué pasará al intentar integrar los cambios?

Una herramienta de merge (o de integración) no detectará el código que se ha movido, pero verá que se ha quitado parte del código y que otra parte se ha añadido. Así que habrá que editar el código manualmente e ir copiando y pegando bloques de código. ¡Un dolor de cabeza!.

¿Y si la herramienta pudiera ayudar?

Lo mejor sería que detectara cuál ha sido el código que se ha movido, pero significaría que habría que realizar algún tipo de análisis sintáctico, que no es lo más sencillo de hacer ya que la herramienta se hace dependiente del lenguaje, etc (y esto es en lo que estamos trabajando en este momento, así que estad al loro...).

Pero, ¿y si tan sólo te dejara que encontraras el código que se ha movido y entonces la herramienta pudiera hacer el trabajo sucio? Te ahorrarías el cortar y pegar, ¿no?

Lo ideal sería tener algo como lo siguiente: que la herramienta detecte que "algo ha pasado", entonces indicaría que se debe de buscar el código que ha sido movido, entonces realiza un "sub-merge" sólo con los contribuidores afectados.

Se realiza el sub-merge, solucionando los conflictos potenciales y la herramienta cambiará tu selección por el código que se ha integrado.

Fácil, ¿no?

Estamos trabajando en una nueva versión de la herramienta de integración de Plastic y la podéis ver en acción en el siguiente vídeo:

¿Los siguientes pasos?

Estos son algunos:

¿Qué pasa cuando el código se mueve a un fichero diferente? Estamos trabajando en ello.

Sistema que detecte de manera automática el código movido

Búsqueda de código movido en ficheros

¡Estad atentos!

Como utilizar Plastic SCM y DevTrack parte I

2008-08-04T11:02:00.015+02:00

Como ya habréis visto en posts anteriores, Plastic SCM ofrecer la opción de ser utilizado integrado con diversas herramientas de control de tareas, ya que se integra con los sistemas más utilizados en el mercado, aquí podéis ver cuáles son estas herramientas. Una de ellas es DevTrack, de Tech Excel.
En este post voy a explicar con ejemplos, como utilizar Plastic SCM integrado con DevTrack. Para comenzar tenemos que tener en cuenta que Plastic no sólo se integra con este sistema, sino que además proporciona diversas opciones para la integración. ¿Por qué se ofrecen diversas opciones? Pues simplemente para que cada organización pueda utilizar el modo que mejor se adapte a su patrón de trabajo; en este post vamos a ver la opción del modo de trabajo "Tarea en Rama".
El primer paso para configurar la extensión de DevTrack por parte del desarrollador será copiar el fichero “devtrackextension.dll” en la carpeta dónde está instalado el cliente de Plastic SCM y añadir las siguientes líneas (rodeadas en rojo) para indicar al cliente que esta es la extensión que se va a usar:

Y además habría que crear un fichero “devtrackextension.conf”, la apariencia por defecto del mismo es la siguiente:


<devtrackextensionconfiguration>
<dtlinkplusurl>http://192.168.1.237/LinkPlusWebService/WSDTIncident.asmx</
dtlinkplusurl>
<user>terry-j</user>
<projectid>daveProject</projectid>
<systemid>daveSystem</systemid>
<branchprefix>issue</branchprefix>
<dtbuginfobrowserurl>http://192.168.1.237/scripts/texcel/devtrack/b
uginfo.dll</dtbuginfobrowserurl>
</devtrackextensionconfiguration>

Finalmente, debemos de asegurarnos de que el fichero devtrackextension.dll esté en la carpeta del cliente de Plastic SCM.

Una vez que se ha configurado la extensión el primer paso para comenzar a trabajar será crear una nueva tarea en nuestro sistema de control de tareas, DevTrack en este caso. En DevTrack las tareas se pueden crear como defecto o como nuevas características, y además se pueden clasificar en diversas categorías.
Al guardar la nueva tarea se puede ver el número que se le ha asignado, además se pueden realizar búsquedas por desarrollador, tipo de tarea, etc. En este caso vemos que se ha creado la tarea 107, y se puede indicar al sistema que envíe un email al desarrollador al que se le encarga esta tarea.

Cuando el desarrollador asignado, en este caso, Terry, esté preparado para comenzar a trabajar en la tarea 107, irá a la vista de ramas para crear una nueva rama a la que pondrá el mismo nombre que la tarea creada en DevTrack e incluirá sus comentarios. También se puede incluir la base que tendrá la rama, que esta recordará cada vez que un usuario vaya a trabajar con ella; se puede ver más información de las ramas inteligentes de Plastic aquí.

Después de que se haya creado la rama, yendo a la parte superior izquierda de la vista de ramas podemos ver la información extendida de las ramas, que muestra informacion de las tareas enlazadas de DevTrack al seleccionar una rama. En la siguiente imágen podemos ver que se selecciona la rama recién creada (/scm00107) y en la parte de la derecha podemos ver inmediatamente la información de la tarea 107 en DevTrack: título, comentarios, propietario,etc:

Y una vez que se haya realizado la tarea, haciendo doble click en el diálogo o click en el botón de la extensión, podemos ir a las tareas en DevTrack, cambiar el estado o cualquier otra información de la tarea, que se refrescará en la información de Plastic:

¡Así de sencillo!

Repositorio de Mono en Plastic

2008-07-28T14:37:00.000+02:00

Estamos trabajando en una sincronización de dos modos de Subversion con Plastic. Permitirá que los grupos de desarrollo que utilizan Subversion puedan migrar a Plastic poco a poco mientras continúan en sincronización con otras localizaciones que tardarán más en moverse a Plastic.

Como prueba estamos importando el repositorio de Mono. Nuestra intención es crear un sitio público en el cual tener proyectos de código libre con Plastic, y por supuesto, el primer repositorio que se va a replicar será el código base de Mono.

Aquí podéis encontrar algunas capturas de la importación preliminar que hemos estado haciendo hoy.
Esta es una vista de las etiquetas:

Ramas:

Un árbol de versiones del directorio de Mono:

Los últimos changesets que se importaron (por favor, tengan en cuenta que no estamos utilizando el último repositorio de SVN)

El explorador de ramas...

Y la vista de contenido de una rama:

Así que aún tardaremos un tiempo, pero espero que publiquemos un repositorio de Mono bastante pronto para que podáis ver las características de Plastic en un repositorio grande tan amplio como conocido.

Como configurar MySQL como backend en Plastic SCM 2.5

2008-07-28T13:23:00.004+02:00

Es muy sencillo de configurar, tan sólo hay que crear (o editar) un fichero denominado 'db.conf' en el directorio de instalación del servidor.
El contenido de este fichero debe de ser el siguiente:

<dbconfig>
  <providername>mysql</providername>
  <connectionstring>Server=_SERVER_;UserID=_USER_;Password=_PASSWORD_;Database={0};Pooling=true</connectionstring>
  <databasepath></databasepath>
</dbconfig>

cambiando los parámetros _SERVER_, _USER_ y _PASSWORD_ con los necesarios según la configuración del servidor que se quiera utilizar. Por ejemplo, un fichero with 'db.conf' ´válido para nuestro entorno de desarrollo sería:

<dbconfig>
  <providername>mysql</providername>
  <connectionstring>Server=venus;UserID=myuser;Password=mypwd;Database={0};Pooling=true</connectionstring>
  <databasepath></databasepath>
</dbconfig>

Finalmente, debemos indicar que el parámetro de configuración de mysql max_allowed_packet soporte hasta 10MB. Para más información de cómo configurar este parámetro puede ver el siguiente artículo.

Cómo utilizar Plastic SCM y Bugzilla II

2008-07-22T10:13:00.001+02:00

Como vimos en el post anterior de cómo utilzar Plastic SCM con la extensión de Bugzilla, hay dos opciones diferentes para trabajar con la extensión, dependiendo del patrón de trabajo que su empresa esté utilizando. En este post nos vamos a centrar en la opción de “Tarea en Changeset” (Task on Changeset), que utilizarán empresas que trabajen con el patrón de desarrollo en línea principal o en “rama por desarrollador”.
Para configurar la extensión con este método de trabajo hay que configurar el fichero “bugzillaextension.dll” de la misma manera que en el caso anterior, pero en este caso el fichero “bugzillaextension.conf” se configura de manera diferente, por lo que debe de tener la siguiente apariencia:


<BugzillaExtensionConfiguration>
 <BugzillaBaseUrl>http://192.168.1.14:8888/bugzilla/
         3.0/</BugzillaBaseUrl>
 <BranchPrefix>SCM</BranchPrefix>
        <WorkingMode>TaskOnChangeset</WorkingMode>
</BugzillaExtensionConfiguration>

¡Y ya está listo para empezar a trabajar!
Como en el caso anterior, empezamos a trabajar creando una nueva tarea en Bugzilla que se asigna al desarrollador denominado “tester”, se deja la tarea en estado de asignada:

En este caso podemos ver que el número de defecto asignado es el 14, tenemos más defectos creados, así que podemos ver la lista de defectos utilizando la herramienta de búsqueda de Bugzilla:

Y como resultado de la búsqueda obtenemos el listado de defectos con estado nuevo, asignado, reabierto o resuelto, como hemos indicado en la búsqueda, y entre ellos encontramos el defecto que acabamos de añadir, con número de identificación 14:

Ahora pongámonos a trabajar y editar el fichero “assfile” como nos indica la tarea asignada: vamos a Plastic, desprotegemos el fichero, lo editamos con los cambios que tengamos que introducir en él y lo protegemos de nuevo: en este punto Plastic abrirá una nueva ventana en la que incluiremos la información de la protección; esta ventana tiene la siguiente apariencia:

En esta ventana el usuario puede incluir los comentarios de la operación de protección y enlazar dicha operación (changeset) con el defecto o defectos relacionados, ya que en la opción de “tarea en changeset” se pueden enlazar uno o más changesets a una o más tareas o defectos.
Si pinchamos en la opción de “Añadir nueva tarea” se abrirá otra ventana desde la cual podremos seleccionar el defecto que queramos enlazar, en este caso vamos a enlazar el defecto 14 como muestra la imagen:

¡Y ya lo tenemos enlazado!, si ahora vamos a la vista de changesets podemos encontrar información de los defectos de bugzilla enlazados a cada uno de los changesets, desde esta vista además podemos enlazar más defectos a un mismo changeset o borrar defectos que se hayan añadido previamente, y como en el caso del método de trabajo “tarea en rama”, podemos ir directamente a ese defecto en Bugzilla, hacer cambios en los defectos y cambiarlos en cualquier momento.

¡Espero que os guste!

Cómo utilizar Plastic SCM y Bugzilla I

2008-07-22T10:10:00.000+02:00

Como probablemente habrá visto ya, Plastic SCM le ofrece la opción de utilizar el sistema de gestión de tareas de su elección ya que se integra totalmente con diversos sistemas del mercado, aquí podrá ver cuales son.
En este post intentaré explicar con un ejemplo cómo utilizar Plastic SCM integrado con uno de estos sistemas, Bugzilla…Lo primero aquí es tener en cuenta que Plastic SCM no sólo se integra con este sistema, sino que además ofrece diversas opciones de integración.
¿Por qué? Simplemente para ofrecer el método de trabajo más adecuado según el patrón de trabajo que utilice su empresa. En primer lugar en este post vamos a ver la opción de “tarea en rama” (task on branch).

Para configurar la extensión de Bugzilla en el cliente se debe de copiar “bugzillaextension.dll”, en el fichero en el que tenga instalado el cliente de Plastic SCM, y se añaden las siguientes líneas (rodeadas en rojo) para indicar al cliente que utilice esta extensión:

Y también debe de crear un fichero “bugzillaextension.conf”. La apariencia por defecto de este fichero es la siguiente:


<bugzillaextensionconfiguration>
     <bugzillabaseurl>http://192.168.1.14:8888/bugzilla/3.0</bugzillabaseurl>
     <branchprefix>SCM</BRANCHPREFIX>

La opción que se fija por defecto es la de “Tarea en Rama” aunque tambien se puede especificar de la siguiente manera:


<bugzillaextensionconfiguration>
 <bugzillabaseurl>http://192.168.1.14:8888/bugzilla/3.0/</bugzillabaseurl>
 <branchprefix>SCM$lt;/branchprefix>
        <workingmode>TaskOnBranch</workingmode>
</bugzillaextensionconfiguration>

Ahora que ya está configurada la extensión el primer paso para empezar a trabajar con ella será crear un nuevo defecto (bug) en el sistema de control de tareas o defectos que vamos a utilizar: Bugzilla:

Se crea un nuevo defecto, en este caso se pone en estado “NEW” (nuevo) y se asigna a “tester”, también podemos incluir el número de horas estimadas y el plazo para realizar la tarea.
El título que se da a esta nueva tarea es “New Task Created: Comments on a file” (Nueva tarea creada: Comentarios en un fichero) y se incluye una descripción de lo que se va a hacer para la tarea.
Al guardar el defecto podemos ver el número que se le asigna en Bugzilla: en este caso es el 13 y podemos además indicar al sistema que envíe un email al desarrollador al que hemos asignado para que lo resuelva para que sepa que se ha encomendado una nueva tarea:

Cuando el desarrollador tester vaya a comenzar a trabajar en el defecto 13, creará fácilmente una nueva rama y la nombrará según el defecto creado en Bugzilla, además de añadir sus comentarios, puede poner los mismos que en el defecto en Bugzilla:

Entonces tendrá que acceder a la parte superior izquierda de la vista de ramas desde la que se muestra la información ampliada de las ramas, que muestra información del defecto correspondiente en Bugzilla al seleccionar una rama. En la siguiente imagen seleccionamos la rama que se acaba de crear (/scm013) y en la parte de la derecha podemos ver inmediatamente la información del defecto número 13, asociado a esa rama: su número, propietario o desarrollador al que se ha asignado la tarea, título y comentarios como muestra la vista normal:
Además está disponible la vista estándar que también muestra el estado del defecto en cada momento:

Y tan pronto como se haya realizado la tarea se hace doble click en el diálogo o simplemente click en el botón de la extensión, que nos llevará a ese defecto en Bugzilla, dónde podremos cambiar el estado que se refresca instantáneamente en Plastic:

¡Simple e intuitivo…que lo disfrutéis!

¡Nueva versión, Plastic SCM 2.5 ya disponible!

2008-07-22T09:16:00.001+02:00

Nos alegramos de poder anunciaros que acabamos de lanzar el nuevo Plastic SCM 2.5, que ofrece un nuevo mundo de posibilidades para tus necesidades de gestión de la configuración.

Esta nueva versión incluye:

El sistema de triggers, demandado por algunos de vosotros, que permite la ejecución de comandos de usuario para tareas tales como instaurar políticas de creación de ramas o crear reglas de formato.
Los triggers de “Antes” y “después” de eventos inician de manera automática acciones cuando tienen lugar los eventos. El sistema de triggers proporciona tanto triggers de espacios de trabajo que se ejecutan desde el servidor de espacios de trabajo (crear espacio de trabajo, configurar el selector, añadir nuevos ítems, protección y desprotección), y los triggers de repositorio que se ejecutan desde el servidor de repositorios (crear rama, atributo, etiqueta y repositorio) en el servidor, y en el cliente se ejecuta el trigger de "update".

Sistema de ramas "smart": El nuevo sistema de ramas que se ha incluido en Plastic SCM permite que los usuarios implementen cualquier tipo de patrón de trabajo ya que las propias ramas "recuerdan" su punto de partida, por lo que cada vez que un usuario cambia a una rama no tiene que configurar su base... y no sólo esto...las propiedades de una rama se pueden ir cambiando pero su historia no se pierde ya que Plastic se encarga de guardarla.

Sistema de atributos: Permite que los usuarios incluyan información adicional en cualquier objeto del sistema. Se trata de un sistema muy potente y altamente configurable ya que los desarrolladores pueden añadir cualquier atributo y cualquier valor para los atributos...y realizar búsquedas utilizando los atributos (como buscar las ramas que han sido integradas, siendo el atributo estado y el valor integrada...; o buscar etiquetas que se han entregado a los clientes A y B, etc).

Las extensiones de Plastic SCM para herramientas de control de tareas (Jira, Mantis, DevTrack, OnTime, VersionOne y Bugzilla) se han mejorado considerablemente: Como se puede observar en la imagen inferior, hemos incluido una opción en la interfaz gráfica desde la cuál se puede ver la información de la tarea asociada en la extensión. Y además hemos extendido la funcionalidad de las extensiones, ahora soportan dos diferentes métodos de trabajo: Tarea en rama o tarea en changeset.
Mejoras en el rendimiento de diversas operaciones como añadir nuevos ficheros, proteger y desproteger al realizarse en bloque: ¡hemos conseguido que estas operaciones sean el doble de rápidas!.

Mejoras en el sistema: en la integración con Eclipse, el importador de CVS y el instalador.

Correción de errores.

¡Hemos logrado un importante avance en esta nueva versión como resultado de un gran trabajo de nuestro equipo de desarrollo!

Problemas de usuarios

2008-07-04T14:15:00.004+02:00

Después de leer el interesante post de Jonathan sobre clasificación de errores, me interesó el artículo del que habla ya que parece un enfoque muy interesante. Hemos tenido problemas en los últimos meses con este tema y parecía una buena opción.

Después de realizar varios ejemplos con distintas variantes de la fórmula decidimos intentarlo por lo que implementé unos cuantos cambios para soportarlo en nuestra herramienta interna de control de tareas (es un poco primitiva pero con muchas opciones de personalización), aquí se puede ver el resultado:

Creo que el método se tiene que ajustar más a nuestras necesidades pero ya se ve una mejora a la opción de tener un campo "prioridad" muy subjetivo para los defectos.

¡Gracias por la estupenda referencia Jonathan!

Por cierto, podéis encontrar el artículo original aquí. ¡Merece la pena!

El modo desconectado de Visual Studio

2008-06-26T11:21:00.027+02:00

A continuación se muestra un resumen del funcionamiento del modo desconectado de Visual Studio 2003/2005.

Cuando no tenemos conexión con el servidor de control de versiones, Visual Studio detecta esta situación y ofrece trabajar en modo desconectado. Aparecerá una ventana como ésta si estamos trabajando con Visual Studio 2003:

O como ésta si estamos trabajando con Visual Studio2005:

Para desconectar manualmente una solución tenemos que pulsar sobre Archivo --> Control de código fuente --> Cambiar control de código fuente ... y pulsar sobre el botón "Desconectar"

Una vez que hemos desonectado la solución, podemos seguir trabajando normalmente aunque no tengamos conexión con el servidor. Cuando queremos modificar un fichero, Visual Studio "simula" el checkout (desprotección). La desprotección no se ha enviado al servidor, por tanto es muy importante reconectar en cuanto se disponga nuevamente de conexión, ya que las modificaciones que se realizan mientras se está desconectado son exclusivamente locales al disco donde se están realizando.

La información sobre si una solución o sus proyectos están conectado o no con el control de código fuente, Visual Studio las almacena en los ficheros con extensión .suo (Solution User Options). Es muy importante que los ficheros .suo nunca estén bajo el control de versiones, sino que sean privados a cada workspace, ya que esta información es diferente para cada usuario.

Cuando una solución está desconectada, Visual Studio deduce el estado de los ficheros únicamente por el atributo de sólo lectura en el disco local. Es un fichero de sólo lectura estará protegido y uno writable estará desprotegido.

La única operación de control de código fuente disponible en modo desconectado es el checkout (desproteger). Cuando se hace un checkout a un fichero, Visual Studio simplemente quita la protección contra escritura a ese fichero en disco.

A la hora de reconectar, Visual Studio busca ficheros sin protección contra escritura y lanza checkouts reales contra el servidor de control de código fuente.

Adicionalmente, para cada fichero se hace un Diff(), y para aquellos que hayan cambiado en disco fuera del control de código fuente Visual Studio da un aviso, indicando que el contenido en disco es diferente del contenido en el control de código fuente:

Algunos problemas conocidos

Varios clientes han reportado en ocasiones problemas al utilizar el modo desconectado, que se enumeran a continuación:

Error no especificado al tratar de desconectar una proyecto o solución

Las pantallas de error que puede obtener son las siguientes (VS2003 y VS2005 respectivamente):

En ambos casos se trata de bugs de Visual Studio. Puede aprender más sobre este tipo de errores en la siguiente dirección:

http://alinconstantin.homeip.net/WebDocs/Scc/_UnspecifiedError.htm

Es más común encontrar fallos cuando se trata de proyectos Web, para los cuáles se recomienda seguir las siguientes pautas:

http://www.codicesoftware.com/releases/webDevelopmentwhitepaper.pdf

En caso de proyectos no Web, una buena práctica a seguir es colocar de forma adecuada en disco la solución y los proyectos. En Visual Studio 2003 ocurre que cuando el fichero de solución está en un directorio más interno que alguno de los proyectos que contiene, Visual Studio no es capaz de manejarlo bien.

Una forma muy sencilla de reproducir el caso es montar una solución con dos proyectos como se describe en la siguiente imagen:

Cuando no se tiene conexión con el servidor, se da un error controlado y aparece el diálogo para desconectar. Una vez que se pulsa en desconectar y se pulsa ok, aparece el "Error desconocido" citado anteriormente.

La forma de evitar este caso es refactorizar el fichero de solución modificando su ruta, de tal forma que la solución siempre esté en un directorio más externo que todos los proyectos que contiene. Algo parecido a la siguiente figura:

En Visual Studio 2005 este problema está corregido.