Xmerge para integrar código refactorizado

16:51 2 Comments

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 :)
  • 2 comentarios:

    Xdiff para ver diferencias de código movido

    13:27 1 Comments

    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!

    1 comentarios:

    Acabamos de lanzar Plastic SCM 3.0!

    15:34 3 Comments

    ¡¡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!! :)
  • 3 comentarios: