Plastic SCM y Windows Vista

0:47 0 Comments

Acabo de instalar Windows Vista en el ordenador de casa. La versión que instalé es la de 64 bits. Por defecto, vista trae instalada una versión de 64 bits del framework 2.0, con la que Plastic SCM puede trabajar sin problemas, pero ... ¿podría Plastic SCM correr sobre la versión 1.1 del framework, la original para la que fue escrito?
Me puse manos a la obra, temiendo algún problema de compatibilidad, pero tras instalar una actualización de seguridad del framework (SP1), Plastic SCM funcionó sin ningún problema. Éste es el resultado:



Buen rendimiento y un aspecto gráfico mejorado. Enhorabuena al equipo de Microsoft.

0 comentarios:

Muéstrame el código

10:41 0 Comments

En un equipo de desarrollo siempre hay ocasiones en la que alguien tiene que echar un vistazo al código de otro programador. Puede ser algo esporádico (desde peer deskcheck) a algo formal (una inspección de código en toda regla), como se describe en Peer Reviews in Software.
En posts anteriores se ha explicado cómo Plastic SCM, con su manejo de ramas, ayuda a que exista aislamiento entre los programadores, imprescindible para que tengan la estabilidad necesaria para trabajar sin interrupciones. Hoy, sin embargo, veremos cómo puede ayudar a que haya comunicación fluida.
Bien, pero dejando a un lado el por qué es bueno o necesario o símplemente inevitable hacerlo... ¿cómo se hace? Hay una respuesta muy sencilla: alguien viene, se sienta en tu ordenador, y comienza a leer el código. Pero esa no es siempre la mejor opción, quizá dos personas deben mirarlo a la vez, o símplemente mientras tú haces algo quieres que un compañero mire el código. En ese caso, ¿cómo lo haces?
Opción A: haces un zip y se lo mandas por correo a tu colega, o se lo dejas en un lugar en la red para que pueda descargarlo. El lo descomprime y le echa un vistazo, compila, prueba... de todo. No está mal. Es una opción. Claro, ¿y si quiere hacer un cambio sobre lo tuyo? Uhm... ¿No se supone que tienes un fantástico control de versiones precisamente para evitar este tipo de problemas? ¿Por qué no lo usas entonces? La respuesta puede ser la siguiente: dependiendo del SCM que tengas, puede que no sea muy buena idea crear demasiadas ramas. Entonces el modo de trabajo de los programadores es: check out, hacer cambios, probarlos, check in. Es decir, sólo se hace check in cuando todo está perfectamente terminado. En ese momento los cambios pasan a estar disponibles para los demás programadores, a través del control de versiones... ¡¡pero no antes!! Mientras no se haga check in, los ficheros modificados sólo están en el disco del programador.
Bien, pasemos ahora a la opción B. ¿No sería mejor usar el control de versiones para este tipo de cosas? Sí, pero para eso se necesita un SCM capaz de manejar correctamente las ramas. Plastic puede hacerlo, y de hecho el modo natural de trabajar sería crear una rama por cada desarrollador, o incluso una rama por cada tarea. (Leer el post sobre cambios de tarea). Con esa situación, el programador que quiere compartir su código símplemente haría check in de sus ficheros. Pasarían de estar en su disco a estar en el servidor, pero no en la línea principal sino en su rama.

Entonces, como muestra la figura, los dos programadores tienen sus workspaces, con sus selectores asociados. Los selectores indican exactamente qué debe descargarse del repositorio al workspace, de acuerdo a unas reglas. Supongamos que cada uno de los programadores tiene su propia rama: el primero una rama llamada developerA y el segundo una rama developerB. El selector del primer programador (el que quiere pasar su código al otro) sería:

rep "default"
br "/main/developerA" label "baseline100"
co "/main/developerA"

Entonces, ¿qué tiene que hacer el segundo programador?
Símplemente fijar el mismo selector para que su workspace contenga lo mismo que el de su compañero. Como decía, nada de zips... Y si durante la revisión encuentra un problema sólo tiene que hacer checkout, y todo funcionará (y por supuesto el sistema sabrá que fue él quien hizo el cambio, aunque la rama fuera propiedad del otro programador).
¿No es más sencillo? Sí, y aumenta la productividad y es menos propenso a fallos y... un sinfín de ventajas... :-)

0 comentarios:

Caso de éxito: Mono

17:10 0 Comments

Han pasado ya un par de semanas desde que la gente del proyecto Mono decidió incluir Plastic como caso de éxito en su web. Ni que decir tiene que para nosotros ha sido una enorme satisfacción ser mencionados en su web! Alguno de nosotros tuvimos la oportunidad de conocer a Miguel de Icaza (y a Lluis Sanchez!) durante el TechEd de Barcelona, y nos impresionó su personalidad. Todavía estamos trabajando en la release para Linux/Mono (la estamos usando internamente), pero esperamos poder hacerla pública dentro de muy poco.
La existencia de Mono, especialmente en plataformas no windows, fue uno de los elemenots que nos decantó hacia la plataforma .NET. De hecho como indica el artículo de la success story, hoy en día cualquier solución de gestión de configuración seria debe ser multiplataforma.
¡¡Muchas gracias al equipo de Mono (y de Novell por supuesto, Frank) por su apoyo!!

0 comentarios:

Selectores a fondo (I)

1:22 2 Comments

Uno de los objetivos de Plastic, como hemos comentado ya en alguna ocasión, es proporcionar características realmente avanzadas, a todo tipo de grupos de desarrollo.
Una de esas características es la capacidad de configurar totalmente el espacio de trabajo.
¿Qué es un workspace o espacio de trabajo? Es el lugar en el disco del ordenador del programador en el que se descargan los ficheros y directorios del repositorio. Un repositorio (una base de datos donde se almacenan todos los objetos: revisiones de ficheros, de directorios, ramas, etiquetas, etc) maneja muchas versiones de los mismos ficheros, pero en un momento dado un programador trabajará sobre una sola versión de cada uno de ellos. Esas versiones de cada fichero y directorio se descargan en el espacio de trabajo. Una vez allí el progrador puede usar su entorno favorito (desde un IDE a la línea de comandos, cuestión de gustos) para compilar, pasar pruebas, escribir documentación, etc.
Bien, queda más o menos claro lo que es un espacio de trabajo (lo que se suele denominar sandbox en Subversion, vista en Clearcase...), pero, ¿cómo se le especifica qué debe descargar exactamente desde el repositorio?
Entra en juego uno de los conceptos más potentes del sistema: el selector.
La imagen explica cual es la función de un selector: en el repositorio, como se decía más arriba, hay muchas versiones de los ficheros y de los directorios. El selector sirve para filtrar y especificar exactamente cuáles de esas versiones deberán descargarse a disco, traerse al workspace. El ejemplo muestra que el fichero foo.c tiene 3 versiones, sin embargo el usuario quiere ver la versión 0. El selector será el encargado de indicar al servidor que efectivamente sea esa la versión a descargar. Y lo mismo ocurrirá con todos los otros ficheros del ejemplo. Se puede ver ya que el selector aporta una gran flexibilidad a Plastic, siendo una característica diferenciadora respecto a muchos otros sistemas de control de versiones.
El selector por defecto de un espacio de trabajo tiene el siguiente aspecto:

repository "default"
path "/"
branch "/main"
checkout "/main"



¿Qué significa?

El selector es un conjunto de reglas que indican exactamente qué debe descargarse en un espacio de trabajo, y también cómo realizar, o más bien desde dónde, la operación de check out. En el caso del selector por defecto la primera regla que aparece se llama repository e indica contra qué repositorio trabajar. Por defecto se trabaja contra el repositorio que el sistema crea automáticamente durante la instalación, que se llama default. Por eso repository "default" significa vamos a trabajar contra el repositorio "default".
Pero una vez especificado el repositorio, hay que indicar a qué path se aplicarán las reglas. Es decir, directorios (e incluso ficheros) diferentes podrían descargarse aplicando reglas distintas... Eso da muchísima potencia al sistema, pero vayamos paso a paso.
Mediante la regla path "/" lo que se indica es: para todo lo que haya dentro del directorio raíz del repositorio "default", se aplicarán las siguientes reglas.
Y las siguientes reglas son: branch "/main" checkout "/main" que quieren decir: coge lo último de la rama "/main" y cuando sea necesario hacer un check out, hazlo también en "/main".
¿Por qué sabe que tiene que coger lo último? Básicamente porque ese es el comportamiento por defecto, si no quisiéramos lo último sino algo etiquetado de una cierta forma, o una versión concreta, se aplicarían otras reglas diferentes. El siguiente selector tomaría todo desde la etiqueta BL0100.

repository "default"
path "/"
label "BL0100"
checkout "/main"

Símplemente se cambia branch por label.
Pero podría especificarse que se descargue una versión concreta de un fichero o directorio. El siguiente selector descargaría la revisión 10 dentro de la rama /main de /src/main.java, y el resto desde la rama principal. El ejemplo muestra, también, cómo componer diferentes reglas.

repository "default"
path "/src/main.java"
br "/main" revno "10"

path "/"
branch "/main"
checkout "/main"

El sistema va interpretando las reglas de una en una.
Si un elemento no puede cargarse con una regla se intenta con la siguiente, y si ninguna logra cargar el elemento, se descarta.
Hasta aquí la primera entrega sobre selectores, queda mucho más, pero para ir empezando es suficiente.

2 comentarios: