Subversion, atributos y otros pensamientos

14:02 0 Comments

Durante las últimas tres semanas Rubén ha estado trabajando en el desarrollo del importador de Subversion. Será una de las nuevas características de la versión 2.0 que sacaremos en breve. Según parece, Plastic será una de las pocas herramientas que tengan un importador de subversion. Así que hemos estado peleandonos con problemas de memoria, rendimiento y algunas de las características de subversion que no terminan de coincidir con conceptos de Plastic. Con suerte estará terminado esta semana.


Los últimos dos días empezó a hacer pruebas de la implementación con grandes repositorios reales de subversion. No hace falta decir que al principio, mientras se trabajaba en el código, se hicieron pruebas con repositorios más pequeños. Así que tuvo algo de tiempo para retomar tareas pendientes del SPRINT anterior. Normalmente es preferible el realizar tareas largas que cortas, pero el poder cambiar a algo diferente mientras se hacía la importación de los repositorios grandes parecía divertido.


Estuvo implementando algunas mejoras del sistema de consultas. La semana pasada Borja terminó el soporte de los atributos así que ahora es el momento de sacarle todo el jugo posible a través de las consultas.
Así que ha modificado el sistema de consultas incluyendo la posibilidad de encontrar objetos asociados a un atributo concreto. Ahora se pueden realizar consultas como la siguiente:

$ cm find branch where attribute = 'status' and attrvalue = 'open'


Esta consulta resuelve una de las peticiones más demandadas por los clientes que es el listado de las ramas que aún no se han integrado siguiendo el patrón de rama por tarea.

Me recuerda al comando de "encontrar merges", que implementó hace un par de meses pero aún no se ha incluido en las últimas versiones.

$ cm find merge where srcbranch = 'br:/main/branch1' and dstbranch = 'br:/main'

Este muestra si hay merges desde la rama1 a la rama principal o no.

Otra característica muy útil utilizando los atributos es la de poder marcar ciertas revisiones con comentarios. No me refiero a un comentario de revisión normal sino a algo que se integra en la revisión, como por ejemplo que se revise posteriormente. Imagina que quieres que otro desarrollador revise un cambio que acabas de hacer, pero sabes que crearás nuevas revisiones y quieres que compruebe ese cambio específico. Se le podría adjuntar un nuevo atributo denominado "comentario" y darle el valor "comprobar".

$ cm mkatt remark

$ cm statt att:remark rev:src\server\dispacher.cs#br:/main/task001#3 "Must be reviewed"


Si ahora quieres buscar las revisiones que tengan este atributo

$ cm find revs where attribute = 'remark' and attrvalue like '%review%'

Y sacará las revisiones marcadas

Todas estas características estarán incluidas en plastic 2.0, que se lanzará dentro de muy poco...

¿Qué elementos deben estar bajo un control de versiones?

11:28 0 Comments

Después de conversaciones con algunos clientes, y varios usuarios del sistemas SCM, me he dado cuenta de que en algunos casos no está claro qué elementos deben incluirse en un control de código fuente y qué elementos no. Intentaré explicarlo en las siguientes líneas.

Por regla general siempre se deberían incluir en el control de código fuente, todos recursos de un proyecto excepto los que sean resultado de sistema de compilación o de generación.

Por ejemplo, el código fuente es evidente que será un recurso a incluir en el control de versiones. ¿Pero qué ocurre con el resto de recursos de un proyecto? Imágenes, scripts de bases de datos, ficheros compilación (make, Ant ...), binarios, documentación, ...

Quizá sea más interesante centrarse en que recursos NO deberían incluirse en un control de versiones.

Todo fichero binario resultado de una compilación o de una generación (reports, etc ...) nunca debería incluirse en un control de código fuente. El entorno debería estar lo suficientemente preparado para compilar y generar todo lo necesario automáticamente (Ant, NAnt, MSBuild, make, ...)

Muchas veces, son los entornos de desarrollo los que hacen este trabajo por nosotros. Por ejemplo, Visual Studio, mediante la integración con el control de código fuente, es capaz de determinar qué elementos incluye en el control de código fuente y cuáles no.

En este proyecto de Visual Studio, las carpetas bin y obj no están incluidas en el control de código fuente.

En otros entornos de desarrollo como Eclipse, NetBeans, etc ..., se pueden definir las llamados patrones de exclude o de ignore. El entorno permite definir elementos que no serán tenidos en cuenta a la hora de añadir al control de código fuente:

Finalmente, cuando no trabajamos con nigún entorno de desarrollo, no queda más remedio que realizar esta tarea "a mano" (podemos crear un script que utilice los metacaracteres del sistema operativo *,?, para hacer los añadidos al control de versiones de forma "automatizada").

Tipos de clientes

16:33 0 Comments

Hace unos días comenzaba a leer un nuevo libro sobre gestión de proyectos software: Manage It! de la gente de Pragmatic Programmers.

Al final del primer capítulo hace una interesante descripción sobre el significado de calidad para las diferentes partes implicadas en el proyecto, y la verdad es que viene a describir también los tipos de clientes que aparecen cuando se lanza un producto.

En primer lugar habla de los entusiastas. Cuando un producto acaba de salir todavía tiene pocos usuarios, que además suelen estar encantados con alguna de las características del producto. En esta fase lo importante parece ser sacar más nuevas características (o mejorar las actuales) para captar más entusiastas.

Entonces llega el momento en el que el producto comienza a usarse mucho más, y aparecen los visionarios. Están interesados en el software pero a cada uno de ellos se le ocurren nuevas necesidades, nuevas funcionalidades que añadir, que el equipo de desarrollo se esfuerza en implementar.

Y llega el momento en el que el producto comienza a ser realmente conocido y a tener un gran número de clientes. Ahora entran en escena los pragmáticos: no quieren nuevas características porque ya les gusta lo que hace el producto, ahora bien, serán muchos y querrán un sistema robusto.

Posteriormente llegan los conservadores. Les ha costado decidirse por el producto pero finalmente van a usarlo. Y, eso sí, protestarán de todo aquello que puedan, de cualquier característica que no esté implementada o de cualquier fallo que otros clientes hayan podido pasar por alto...

Y al final, cuando el producto ya es muy maduro (incluso en declive desde el punto de vista técnico), entran en juego los escépticos: quizá no lo compren nunca, pero si lo hacen es posible que generen dinero en temas como soporte... Los productos que llegan a esta fase normalmente se conocen como productos vaca (o cash cows): generan dinero por poco esfuerzo (claro, descontando todo el que ya se ha hecho anteriormente....)

¡Estamos de enhorabuena!

12:37 1 Comments

Una vez más recibimos una grata noticia: ¡hemos sido galardonados con un nuevo premio!

En esta ocasión se trata del Premio al Producto más Innovador dentro de los premios que otorga la revista Castilla y León Económica.

Esta es la primera edición de estos premios, patrocinados por el ForoBurgos y convocados con el objetivo de reconocer las mejores iniciativas del tejido empresarial de Castilla y León así como valorar la gestión de los directivos y su contribución a la modernización y eficiencia de sus empresas.

La categoría en la que Plastic SCM ha sido premiado, es la de Producto mas Innovador, por lo que nos han destacado como la empresa que ha lanzado el producto más innovador, que aporta valor añadido y ha tenido un gran éxito en el mercado.

La entrega de premios se celebrará el día 8 de Noviembre en Valladolid.

Podéis ver la noticia aquí.

!Nueva versión BL063.5 disponible!

17:36 0 Comments

Acabamos de lanzar la nueva versión de Plastic SCM (internamente BL063.5), y nos hemos centrado en las demandas de nuestros clientes, ya que muchos de vosotros nos habíais pedido que incluyeramos integraciones de Plastic SCM con herramientas de control de tareas.

Y esto es lo que hemos incluido en esta nueva versión:

• Integración con JIRA: El software de Atlassian JIRA ofrece características fiables de mapeo de datos que permiten la transformación de diversos tipos de datos con PlasticSCM. Cualquier empresa puede utilizar JIRA para mejorar aún más las caracterísitcas de gestión de la configuración de Plastic SCM.
• Integración con Bugzilla: Este conocido sistema de control de tareas elabora informes y asigna cada error al desarrollador más apropiado; se puede utilizar para llevar una lista de tareas pendientes así como para priorizar y programar tareas. La integración de Plastic SCM con Bugzilla ofrece una potente solución para el ciclo de vida del desarrollo, aumentando la productividad del equipo de trabajo.
• Integración con Trac: Trac es una herramienta de control de tareas gratuita que proporciona un enfoque minimalista de la gestión de proyectos web. La integración de Plastic con Trac asegura que el esfuerzo y el tiempo empleados en administrar el sistema sean mínimos además de proporcionar un seguimiento completo de todo el trabajo realizado en desarrollo.
• Integración con OnTime: OnTime es una herramienta comercial desarrollada por la empresa Axosoft, muy útil para enlazar defectos, características y tareas con las ramas Plastic. Cada rama de Plastic corresponde a una tarea asociada en OnTime: el resultado será una solución de Gestión de Ciclo de vida del proyecto completa y muy potente.
• Integración con Mantis: La integración de Plastic SCM con permite que cada equipo lleve a cabo el proceso de desarrollo según sus necesidades; garantiza que el grupo de desarrollo esté en todo momento sincronizado con el equipo de QA.

Para información más detallada podéis entrar aquí.

CÓDICE SOFTWARE APOYA A 4 EMPRESAS DE CASTILLA Y LEÓN EN LA OBTENCIÓN DE CMMi

11:12 0 Comments

Desde finales de 2006 Códice Software ha prestado su apoyo al proyecto Competic, una iniciativa enmarcada dentro del Plan Avanza y liderado en Castilla y León por AETICAL, a través del cual 5 empresas de la región han logrado CMMi nivel 2.

La participación de Códice se materializó mediante la aportación de un consultor regional al proyecto, papel desempeñado por Mercedes Quintanilla, responsable de calidad, que previamente había liderado el proyecto CMMi interno de la empresa, que terminó con éxito en Marzo de 2007 convirtiendo a Códice en la primera PYME española en obtener una certificación CMMi.

El proyecto terminó el pasado Junio con un importante éxito: 5 de las 8 empresas participantes lograron una evaluación positiva en CMMi nivel 2. El éxito también fue importante para Códice ya que 4 de las 5 empresas habían recibido el apoyo directo de su consultora regional.

El Proyecto Competic ha sido promovido como parte del Plan AVANZA del Ministerio de Industria, Comercio y Turismo y ha contado con la colaboración de asociaciones autonómicas de TICs. Tras el éxito que ha supuesto esta primera edición, CONETIC pretende continuar a lo largo de los años 2007, 2008 y 2009 con una segunda edición del proyecto en la que participarán de nuevo empresas de todo el país, algunas con el objetivo de alcanzar el nivel 3 de Madurez y otras para lograr el nivel 2.

CMMi (Capability Maturity Model) es el modelo de calidad para empresas de software más reconocido a nivel internacional que clasifica a las empresas en niveles de madurez. Los beneficios que aporta la implantación de este modelo a las empresas pasan por la adherencia en los procesos, ahorro en costes de desarrollo, importante mejora en la productividad así como en la planificación y mejora en la calidad del software terminado lo cual lleva a una mayor satisfacción de los clientes.

Códice Software se centra en el desarrollo de software de control de versiones y gestión de configuración. Su producto, Plastic SCM, se abre camino en el competitivo mercado internacional de soluciones de control de versiones, una de las mayores áreas de crecimiento en los últimos años, dada su fuerte influencia en la producción de software de calidad. Plastic SCM es una alternativa potente y flexible a los sistemas de gigantes del software como IBM, Microsoft o Borland.

¡Nueva Versión BL063.3 disponible!

15:08 0 Comments

Acabamos de sacar la nueva versión de Plastic 1.5.63.3 (internamente la denominamos BL063.3), esta vez nos hemos centraddo en corregir pequeños errores pero también hemos incluido varias características nuevas:
La primera es el Sistema Avanzado de Consultas, que está disponible desde la línea de comandos a través del cm query command.
Este sistema ofrece mayores posibilidades de búsqueda que nuestro Sistema de Consultas: ¡si algo está en el repositorio nuestro Sistema de Consultas Avanzado lo encontrará!
Está basado en gramática SQL, por lo que pregunta directamente a la base de datos del servidor de Plastic.
Las consultas se pueden realizar en una entidad o en varias a la vez, siendo las entidades soportadas cualquier objeto del repositorio, como ítems, ramas, revisiones, etiquetas o changesets.

Echa un vistazo a este ejemplo de una consulta bastante compleja:

cm query
"SELECT BR1.NAME, R1.ITEMID as ITEMPATH
from REVISIONS R1, REVISIONS R2, BRANCHES BR1, BRANCHES BR2, LINKEDOBJECTS LO, LINKS L
where LO.SOURCEOBJECTID = R1.OBJECTID
and R1.BRANCHID = BR1.OBJECTID
and LO.DESTINATIONOBJECTID = R2.OBJECTID
and L.OBJECTID = LO.LINKIDand R2.BRANCHID = BR2.OBJECTID AND BR2.Name='main' AND L.NAME='merge' AND R1.ITEMID=SolvePath(c:\workspace)"
--solvePath=ITEMPATH

El resultado sería el siguiente:

NAME ITEMPATH
scm0205 c:\workspace
scm0831 c:\workspace
SCM0562 c:\workspace
SCM1371 c:\workspace
scm1755 c:\workspace


Ejemplo de una consulta sobre las ramas creadas por un usuario:

La otra novedad de esta versión es una mejora en el desarrollo en paralelo en una sola rama.

Plastic soporta diversos patrones de desarrollo, siendo el más aconsejado por nosotros el de "rama por tarea", pero si prefieres trabajar en una sola rama te gustará esto:

Cada desarrollador trabaja desde la última revisión de la rama main; si dos desarrolladores desprotegen esta revisión...cuando el primero de ellos proteja sus cambios lo podrá hacer sin problemas: sus cambios se incluirán como una nueva revisión. ¿Pero qué pasa cuando el segundo desarrollador vaya a proteger sus cambios? Al haberse creado una nueva revisión Plastic antes simplemente le indicaba que era necesario realizar un merge.

Desde ahora, cuando este segundo desarrollador vaya a proteger sus cambios, Plastic actualizará automáticamente el contenido de su repositorio y le mostrará el diálogo de merge; el resultado será una nueva revisión que incluirá los cambios realizados por ambos desarrolladores.

¡Esta mejora no sólo está disponible desde la herramienta gráfica de Plastic sino también desde la integración con Visual Studio, por lo que tu trabajo podrá ser más rápido y productivo!

¡Esperamos que disfrutes de esta nueva versión!

Nuevo diseño del árbol en 3D

11:46 0 Comments

Nuestro equipo ha estado trabajando en el nuevo algoritmo de diseño para el árbol de versiones en 3D de Plastic.
Con extensas revisiones, el árbol tiene ahora un comportamiento cónico, se va haciendo más ancho hacia el final, con lo cual es más dificil de comprender.
Así que han cambiado el algoritmo para utilizar un tipo de diseño en espiral: las ramas se distribuyen en el espacio siguiendo una ruta espiral, que comienza desde el centro del árbol en cada bucle para ahorrar espacio.
Daniel también pidió el añadir (finalmente, ya que es una característica por la que se ha esperado mucho tiempo) la funcionalidad de localizar las revisiones y las ramas. También se ha implementado un filtro por fechas: ahora puedes seleccionar una fecha un período de tiempo y sólo se crearán las revisiones en ese período.
El nuevo árbol en 3D estará integrado en la BL067 y se lanzará junto con plastic 2.0. Supongo que los creadores de la GUI de Códice le limpiarán un poco la cara antes :-) pero las nuevas funcinalidades estarán disponibles. Podéis ver un vídeo en el canal de Códice en YouTube:

P.S: el viernes pasado uno de los vídeos de la GUI 2.0 llegó a la lista de los más vistos en YouTube en España... entre un montón de vídeos de fútbol... :-)

Más de la nueva GUI

11:39 0 Comments

Acabamos de sacar un nuevo vídeo del nuevo cliente gráfico (aún en desarrollo).

Plastic 2.0 pre

11:16 0 Comments

Estamos en estos momentos trabajando en varios proyectos que llevarán a la creación de la próxima versión: Plastic 2.0.

Algunos de los cambios y características se han anunciado con anterioridad (¿que será lo siguiente?).
La característica en la que estoy trabajando es la nueva GUI. Estamos a punto de utilizarla de manera interna esta semana, así que espero que el equipo me pueda dar sus opiniones respecto a usabilidad. La nueva apariencia es una gran cambio respecto a lo que habéis visto hasta ahora de Plastic, con ello intentamos conseguir varios objetivos:

- Crear una mejor interfaz para gestionar diversas vistas de la información
- Ofrecer un diseño atractivo para los usuarios
- Simplificar el obtener información de la herramienta, haciendo que las operaciones más utilizadas sean aún más sencillas
- Crear nuevas posibilidades de integraciones con herramientas de terceros e incluso nuevos desarrollos de Códice para crear algún tipo de entorno virtual en el que colocar ventanas.

Aquí se pueden ver los resultados de una versión preliminar:

¡Espero que os guste y que estéis atentos a las novedades!

El servidor de Plastic en Linux

17:18 0 Comments

Linux ha sido para nosotros un objetivo principal desde el principio del proyecto. Todavía estamos intentando poner nuestra herramienta gráfica en la mainline (gracias a nuestros compañeros de mono), pero el servidor lleva varios meses en funcionamiento.

De hecho muchas empresas parecen estar interesadas en desarrollar con servidores Linux y clientes basados en Windows. Y este es el escenario que voy a describir.

Plastic 1.5 (BL063 para nosotros) incluye varias mejoras en el instalador de Linux para facilitar la configuración. Ahora no tienes que instalar un backend DB separado ni la plataforma de mono, ambos están incluidos por defecto.

He utilizado un OpenSuse en blanco (bueno, realment la imagen vmware de http://www.blogger.com/www.go-mono.org) y el proceso no debería tardar más de 5 minutos, a no ser que tu disco duro sea muy lento.



El primer paso será [obvio] descargar el paquete de instalador de Linux que puedes conseguir aquí. El nombre variará de una versión a otra, ahora se llama PlasticSCM-professional-1.5.63.2-linux-installer.bin.

Una vez que lo tengas en tu máquina ajusta los permisos para hacerlo ejecutable.



El instalador se crea con Bitrock InstallBuilder por lo que puede funcionar tanto en instalación de línea de comandos como en modo gráfico. No quiero que ningún administrador de sistema se queje así que seguire el modo basado en texto...



Sólo hay que ejecutar el fichero bin y comenzará a hacer preguntas: seleccionar el idioma, especificar un directorio, aceptar la licencia, seleccionar los componentes que haya que instalar (estamos instalando el servidor así que sería suficiente con instalar los componentes del servidor y el cliente en línea de comandos) y luego comenzará a copiar ficheros. Opcionalmente se pueden instalar los plugins de Eclipse y JDeveloper (y si estás trabajando en Windows también el de Visual Studio).





Una vez que se copien los ficheros (por defecto en /opt/PlasticSCM) se pueden instalar tanto el servidor como el cliente en línea de comandos, que nos ayudará a comprobar si el sistema está en funcionamiento.

La primera pregunta será la selección del idioma, y entonces pasará a configurar el método de seguridad, que se refiere al método de autenticación con el que trabajará el servidor. Este es un paso bastante importante ya que si no se configura bien, los clientes no se podrán conectar al servidor y habrá que arreglarlo....

Echa un vistazo a las opciones disponibles:

• "Name working mode": el servidor cargará la lista de usuarios de la máquina en la que está funcionando. Si los clientes que se conectan están trabajando en cuentas con el mismo nombre el servidor los reconocerá como usuarios autenticados. Como puedes ver, es un método muy fácil de configurar pero dependerá de lo potente que sea la red. Si no eres un administrador de sistema muy cuidados es muy fácil que haya problemas con los usuarios. Por otro lado es bastante útil si sólo quieres evaluar Plastic o lo necesitas como interoperador entre Windows y Linux. Asegúrese de que el servidor conoce su nombre de usuario.
• "NameID working mode": es igual que el anterior pero en este caso se comprueba tanto el nombre como el ID. En los sistemas Windows el ID es el SID del usuario. En los sistemas Unix es el id de usuario. Es un sistema más potente que el anterior para Windows pero menos en grupos Linux a no ser que se controle lo que se puede adjuntar a la red. Es una buena opción para autenticación basada en NIS.
• "LDAP working mode": ¿tienes en tu red un servidor LDAP? Sería muy fácil de utilizar para un escenario mixto Windows/Linux scenario. Tendrás que dar credenciales de conexión al servidor y validar los usuarios con los nombres. Para autenticar se utiliza el ID interno. El servidor necesitará una combinación de usuario/contraseña para poder recuperar la lista de usuarios y IDs. Este método sólo se puede utilizar para conectar sistemas Linux/Unix a servidores de Directorio Activo.
• "AD working mode". AD se refiere a Directorio Activo. Si estás trabajando en modo de AD en un servidor Windows no tienes que configurar usuarios ni contraseñas, el servidor será capaz de recuperar los usuarios y sus contraseñas de modo automático. Este método es compatible con el método LDAP: puedes configurar el servidor Linux en modo LDAP y los clientes en AD, por ejemplo.

En el ejemplo de la imágen estoy conectando nuestro servidor interno a 192.168.1.3, el nombre del dominio es codicefactory.com, y el servidor utilizará mi propio usuario para autenticarse.

Ahora habrá que indicar si el servidor es un Directorio Activo o un servidor standard LDAP.

También se puede seleccionar el puerto TCP en el que estará el servidor de Plastic.
Después de estas configuraciones el servidor se pondrá en marcha.

El siguiente paso será configurar el cliente. Hemos dicho que utilizaríamos Linux sólo como servidor, pero suele ser una buena idea configurar también el cliente en línea de comandos para comprobar que el servidor está funcionando correctamente.

La imagen muestra los pasos para configurar el cliente.

Ahora podemos teclear un comando para comprobar si el servidor está en funcionamiento. Utilizaremos cm lwk para listar los espacios de trabajo disponibles, y como no se ha creado ninsguno obtendremos un listado vacío.

Ahora deberias instalar el cliente de Plastic en Windows y configurarlo para que se conecte a tu servidor Linux. Tendrás que seleccionar el idioma y después el método de autentiación. Acuérdate de configurarlo según el mecanismo que has indicado en el servidor. El último paso será seleccionar la ubicación del servidor: debes de indicar la dirección IP o el nombre y el puerto. Por defecto se utiliza el puerto 8084 pero se puede cambiar al configurar el servidor.

El servidor está instalado en el /etc/rc directories, por lo que se pondrá en funcionamiento cuando se ponga en marcha el sistema. Para parar el servidor de modo manual run /opt/PlasticSCM/server/plasticd stop. /opt/PlasticSCM/server/plasticd start y se pondrá en marcha.
Si has intentado instalar la nueva versión Plastic 1.5 te habrás dado cuenta de que tardas más tiempo (mucho más) en leer los paso a seguir para realizar la instalación que en llevarla a cabo.

¡Prueba el nuevo servidor en Linux y cuéntanos!

SCRUM y CMMI en DDJ

16:55 0 Comments

Acabamos de publicat un nuevo artículo en DDJ sobre nuestra experiencia en CMMi utilizando SCRUM. Hemos intentado explicar los problemas con los que nos encontramos y cómo intentamos centrarnos en trabajar con un método ágil mientras estábamos evaluándonos en CMMi.

Estadísticas desde el sistema de consultas

16:12 0 Comments

El sistema de consultas es una de las novedades de Plastic 1.5. Ofrece nuevas posibilidades para crear estadísticas a medida y saber cuál es la situación del desarrollo.

Queríamos hacer el sistema de consultas lo más simple posible (siempre puedes quejarte aquí si no te gusta), y por eso decidimos crear una sintáxis tipo SQL. De este modo, teniendo en cuenta que nuestros usuarios son desarrolladores, les ofrecemos una interfaz familiar.

Imagina que quieres hacer un listado de las revisiones creadas desde ayer. En mi caso escribiría:
$ cm find revs where date “>” ‘2007/08/9’ and owner = ‘pablo’

¿Y si quisieras dar formato a toda esta información? Puedes utilizar el modificador de formato y escribir algo como:
$ cm find revs where date “>” ‘2007/08/9’ and owner=’pablo’ –format=”{date} {type} {owner} {item}#{branch}”


Puedes ver que acabo de modificar elementos en un par de ramas. También podría hacer un listado de las revisiones modificadas en una rama concreta añadiendo la condición:

and branch=’br:/main/FixBL063/SCM2199’ a la consulta anterior, como se puede ver en la siguiente captura.

Puedes ver más de los objetos de los que se puede buscar información tecleando: cm showfindobjects. En este momento se pueden buscar revisiones, ramas, changesets, enlaces y usuarios.

Por ejemplo, tecleando “cm find user” se obtienne una lista de los usuarios que tienen objetos dentro del sistema.

También se puede obtener una lista de los changesets con:
$ cm find changeset where owner='pablo' and date ">" '2007/08/01'

Ahora imagínate que quieres saber cuales son todas las ramas que has creado hasta el momento: se puede hacer con

$ cm find branch where owner=’pablo’, en mi caso.

Vale, esto tiene buena pinta para poder hacer un seguimiento de qué es lo que ocurre en el proyecto, con los cambios que alguien ha realizado, etc. Pero, ¿cómo se obtienen estadísticas?

Una de las ventajas del cm find es que puedes exportar la información con formato XML. Prueba algo como:

$ cm find revs where date ">" '2007/08/1' --xml --file=statsAgo.xml

para crear un fichero con toda la información sobre las revisiones creadas a partir de una fecha en concreto. Una vez que tengas el fichero XML puedes empezar a probar opciones con él con tu herramienta favorita.

Importé los datos generados por el cm find en Excel 2007 y entonces empecé a hacer pruebas con las pivot tables. En la nueva versión 2007 esta característica está un poco escondida: ahora está en el menú insertar en vez de en el menú de datos.

Una vez que hayas creado la tabla de los datos importados puedes empezar a agruparlos. Entonces puedes mostrar las revisiones agrupadas en ramas, incluyendo gráficos bastante curiosos.

Mostrar las revisiones agrupadas por usuario.



O incluso calcular cómo se distribuye la revisión creada en cuanto a horas (puedes descubir cosas interesantes).


O semanalmente:



Estamos trabajando en ampliar el sistema de consultas para ofrecer un modo fácil (y potente) de localizar por ejemplo integraciones. También hemos desarrollado un subsistema que llamamos "sistema avanzado de consultas" (no está oficialmente disponible pero estará en la próxima versión BL63.3) que permite buscar directamente en el esquema relacional.

Tomando el sistema de consultas como punto de partida implementaremos un nuevo módulo de Plastic (aún no hemos comenzado), para ofrecer los gráficos directamente desde la herramienta gráfica.

¡Esperamos que os haya gustado!

Rendimiento de GIT vs PLASTIC

14:16 0 Comments

¡Rendimiento! Me estoy empezando a obsesionar con esta palabra. Casi desde el principio del proyecto el rendimiento ha sido una de mis principales preocupaciones: el poder realizar las operaciones de update (obtener) cada vez más y más rápido.

Si recuerdo bien, varios meses antes de lanzar nuestra versión inicial ya estaba comprobando si Plastic era más rápido que Perforce actualizando el espacio de trabajo, una de las operaciones más comunes de un control de versiones.

Hubo un momento en el que éramos capaces de superar a Perforce (que dice ser la solución SCM rápida del mercado), con lo que estaba tremendamente satisfecho. Sabía que Perforce era aún más rápido que Plastic haciendo protecciones y añadiendo nuevos fichero, pero nosotros éramos más rápidos actualizando el espacio de trabajo.

Después realicé un test para comparar Plastic y Subversion y…haciendo la operación de “obtener todo” (que descarga de nuevo todo el contendido al espacio de trabajo), ¡y resultamos ser tres veces más rápidos!

En las últimas semanas he estado trabajando en un cambio importante en el código del selector. ¿Qué quiere decir esto? Bueno, pues los selectores son la pieza clave del sistema de Plastic, tanto si son visibles como si no (la opción visible tan sólo está en la versión profesional de Plastic, pero de todos modos muchos usuarios no quieren preocuparse del selector y prefieren el mecanismo de “cambiar a rama”), juegan un papel importante en el sistema de Plastic.
En resumen: las revisiones no se “enlazan directamente” a los directorios que las contienen (como ocurre con los “sistemas de rutas de ramas”) como TFS, Perforce, Subversion, etc) sino que el sistema tiene que resolver cuándo una revisión depende del selector.

¿Significa esto que la misma revisión de un fichero podría incluirse en diferentes ubicaciones con sólo cambiar el selector? ¡Si, eso es exactamente lo que significa!

El mecanismo es extremadamente potente, pero como contrapartida no es especialmente fácil de implementar. A cambio obtienes renombrado real y muchas otras posibilidades, pero el sistema tiene que realizar una búsqueda para calcular dónde está localizado cada elemento.

La versión de Plastic BL064 tiene un nuevo mecanismo para resolver el selector que supone una importante mejora respecto al anterior. Ahora no solo es rápida la operación de "obtener todo" , sino también el detectar qué se tiene que cambiar si alguien realizó un cambio en la rama en la que está trabajando. El nuevo sistema es muchísimo más rápido.

-“¿BL064? ¿De qué estais hablando? Acabáis de sacar Plastic 1.5 hace unas semanas…-Puedo oír como algunos os quejareis … :-)

Nosotros utilizamos un esquema de numeración de desarrollo interna (que también está disponible en la versión externa, podéis echar un vistazo a la información de cada versión de los ejecutables), por lo que nuestra versión 1.5 es realmente la BL063. Pero en este momento estamos utilizando la BL065 internamente como soporte de nuestro desarrollo. Así que me temo que las mejoras de las que estoy hablando aún no están disponible, un poco de paciencia…

Estaba muy satisfecho con el nuevo sistema del selector, pero de repente me acordé de GIT…Pensábamos que éramos lo más rápidos en las actualizaciones pero probé GIT y…bueno, pues es una herramienta fea y tonta :-), pero es muy rápida…

Así que instale de nuevo GIT 1.5.2.4 en nuestro Linux FC4, que tiene un par de Intel(R) Xeon(TM) CPU 3.00GHz. Tiene más de dos años pero va bastante rápido.
$ uname -a
Linux juno 2.6.11-1.1369_FC4smp #1 SMP Thu Jun 2 23:08:39 EDT 2005 i686 i686 i386 GNU/Linux.

Importé una versión de nuestro código en un repositorio de git. Quité todos los ficheros locales (¡menos el subdirectorio .git, claro!) e hice un “git checkout .” que recrea todos los ficheros. Tardó unos 20s…

Después probó el mismo escenario con Plastic (BL065). Tardó unos 29s. Si, GIT es más rápido pero… el servidor de Plastic se reinstaló, con lo que todo el contenido se descargó a través de nuestra red local de 100Mbps!!!

Para poner mayor dramatismo tengo que decir que la prueba se realizó contra nuestro servidor real que no solo tiene una copia del repositorio (como en el caso de GIT) sino de todo el desarrollo, pero no habría habido gran diferencia si el servidor tuviera sólo una copia ya que el tamaño no afecta al rendimiento.

La mala noticia (para mi) es que repetí la operación en git (después de haber quitado todo) y tardó solamente 8s. No se exactamente el motivo (¿cachés en disco?) pero si lanzo el “rm –rf *” justo antes de lanzar el “git checkout .” tarda mucho más que si dejo cierto tiempo entre ambas operaciones. Plastic tiene un rendimiento homogéneo de entre 28 y 30 segundos, no se ve afectado por la operación de borrado.

“Vale, pero ¿qué pasa cuando el servidor de Plastic está instalado en la mismo máquina que el cliente? ¿No sería un escenario más real y daría un rendimiento incluso mejor?", podríais preguntar...

Me temo que si queréis conocer la respuesta tendréis que esperar al siguiente capítulo … :-)

Visualización en PlasticSCM

18:04 0 Comments

Estos días hemos estado estudiando cómo mejorar nuestro trabajo diario con nuestro propio sistema. Hemos tratado de identificar las costumbres que tenemos a la hora trabajar, sobre qué elementos realizamos más cambios cada uno de nosotros, que elementos son los más modificados, etc.

Para realizar este estudio, utilizábamos el sistema de consultas, pero finalmente, por comodidad, hemos desarrollado una pequeña aplicación para poder hacerlo de forma visual mucho más fácilmente.

Esta aplicación se encarga de mostrar los cambios que ha realizado cada usuario, y los que ha sufrido cada elemento, permitiendo ver cuales son los usuarios más activos o los elementos sobre los que más se trabaja en el sistema. Y en caso de quedar alguna duda (por no estar juntos) por medio de la ordenación se puede ver con bastante facilidad.


Pero donde se ha tratado de obtener una mayor información es a través de la interacción. Cuando se selecciona un usuario, la región del usuario es dividida en tantas subregiones como elementos haya modificado (teniendo un tamaño proporcional al numero de cambios que ha realizado en cada elemento) y adicionalmente en cada elemento se crea una región con los cambios que ese usuario ha realizado en ese elemento de forma que se ve en que elementos trabaja y de estos en cuales trabaja con mayor o menor frecuencia.


Al igual que pasaba cuando se seleccionaba un usuario, si se selecciona un elemento, la región del elemento es dividida en tantas subregiones como usuarios lo haya modificado y en la región de cada usuario se indica que parte de sus cambios han sido realizados sobre ese elemento.


Aunque es una herramienta que se encuentra en una fase beta y de momento sólo está pensada para uso interno, más adelante se incluirá como parte del producto, una vez haya sido pulida, refinada y completada con la funcionalidad que le falta. No obstante si alguien quiere usarla conjuntamente con PlasticSCM, se puede poner en contacto con nosotros para que se la pueda descargar y le expliquemos como usarla en combinación con el sistema de consultas.

Caso de éxito con Intel

13:02 0 Comments

Intel acaba de publicar un caso de éxito sobre el modo en que hemos optimizado Plastic SCM para su gama de procesadores.

La noticia completa, en inglés, aporta toda la información sobre la colaboración.

¿Qué será lo siguiente?

12:42 0 Comments

Hace unos días hemos publicado la nueve versión Plastic SCM 1.5,
nuestro gran lanzamiento tras la inicial, 1.0, el paso Noviembre. Hemos intentado incluir en la nueva versión funcionalidades que nos habían solicitado algunos de nuestros clientes, haciendo que Plastic sea lo que necesitan los usuarios, o al menos es lo que hemos intentado.

Pero, ¿que será lo siguiente? ¿Qué podéis esperar encontrar en la siguiente release de Plastic SCM? Aquí podéis ver un pequeño listado de cosas que vamos a sacar MUY pronto (algunas de las mejoras ya han sido implementadas y sólo tienen que pasar por los juegos de tests):

• Integración con Jira: una de las características ya implementadas. Plastic se integrará totalmente con este popular sistema de control de tareas. Estará disponible tanto para el servidor (en JIra) como para el cliente (pudiendo realizar las tareas asociadas desde Plastic).
  


• Mejoras en los importadores de CVS y SourceSafe: habrá un nuevo asistente para las importaciones que ayudará a los usuarios a migrar desde CVS o SourceSafe a Plastic. El asistente disponible actualmente está basado en la línea de comandos, y el nuevo también estará disponible desde la interfaz gráfica.
  


• Sistema de seguridad basado en Usuario/contraseña: la mayor parte de nuestros usuarios integran Plastic con directorio LDAP, pero como algunos clientes nos han solicitado, tendremos disponible un nuevo sistema de autenticación basado en usuario/ contraseña. Con este nuevo sistema las empresas que no utilicen Directorio Activo o no quieran utilizar los usuarios de su sistema operativo, podrán utilizar Plastic en su entorno. Este sistema también será útil para el uso de servidores disponibles desde internet.
  


• Mejoras en la integración con Eclipse: estamos trabajando duro en conseguir la integración total de Plastic con Eclipse para ayudar a los desarrolladores de Java en su paso a Plastic. En breve tendremos una nueva vista de desprotecciones, un mejorado sistema de refactor y una nueva barra de herramientas.


• Servidores de repositorio y espacios de trabajo independientes: se podrán configurar tantos servidores de repositorios como sea necesario, lo cual es importante para grandes proyectos; y también se podrán crear todos los servidores de espacios de trabajo que sean necesarios. Rendimiento: El conseguir cada vez el mejor rendimiento es siempre una de nuestras principales metas...

Hemos conseguido grandes mejoras en nuestro sistema "solve path", que es el responsable del mapeo entre las revisiones y sus ubicaciones según el selector. Ahora el detectar cambios (la descarga de datos ya era bastante rapida) será mucho, mucho más rápido que antes...

Los anterior son mejoras que ya están implementadas y casi listas para incorporar en Plastic SCM, pero, ¿en qué nos centraremos en los próximos meses?

• Integración con Trac
  


• Importador de Subversion


• Soporte avanzado de ramas


• Soporte para el desarrollo distribuido


• Sistema de workflows


• MySQL backend


• Nueva interfaz gráfica con diversas vistas y mejoras en visualización
  

¡Nuevo Plastic SCM 1.5!

11:23 1 Comments

¡ Nos complace anunciar que ya está disponible el nuevo Plastic SCM 1.5 !

Plastic SCM 1.5 incorpora numerosas novedades y mejoras sobre la versión 1.0 y supone un paso adelante importante en la evolución del producto. Las características más importantes de Plastic SCM 1.5 se pueden encontrar a continuación:

• Sistema de consultas: La nueva release de Plastic SCM incorpora un potente sistema de consultas capaz de obtener gran cantidad de información sobre los datos almacenados en los diferentes repositorios.
• Nuevo sistema de seguridad: Las nuevas incorporaciones permiten aplicar la seguridad sobre árboles de directorios (además de la jerarquía de ramas y repositorios ya existente), simplificando el trabajo con permisos. Se introduce también un nuevo tipo de usuario propietario que posibilita establecer permisos especiales a los propietarios de todos los objetos controlados por Plastic.
• Gráfico de ramas: Es una de las características más esperadas de la nueva versión de Plastic SCM. A partir de ahora será posible visualizar la evolución de un proyecto mediante esta nueva visualización, que junto al árbol de versiones en 3D marca una diferencia sustancial con todos los mecanismos de visualización existentes en el ámbito del control de versiones.
• Mejoras en el sistema de merge: Este sistema se ha mejorado para la versión 1.5. El sistema de merge de Plastic SCM es uno de los más potentes y robustos ya que incorpora características como merge tracking y seguimiento de refactors además de un cálculo optimizado de contribuidores. Durante los últimos meses se ha trabajado intensamente en mejorar todavía más el sistema, mejorando sensiblemente el rendimiento y ofreciendo un mejor soporte a operaciones que impliquen renombrado.
• Soporte de SQL Server: Plastic SCM, como sistema de nueva generación, se apoya en un backend de base de datos relacional que puede ser reemplazable y configurable por el usuario.La primera versión oficial de Plastic SCM incorporaba únicamente soporte para Firebird (http://www.firebirdsql.org), un sistema gestor de base de datos open source muy potente y fiable. Aunque la apuesta de Plastic por Firebird sigue siendo clara, se ha incorporado soporte de SQL Server (versiones 2005 y superiores) de modo que las empresas puedan aprovechar mejor su infraestructura existente.
• Integración con PowerBuilder: Plastic SCM incorpora un plugin SCC compatible con Visual Studio y con otros muchos entornos de desarrollo que implementan SCC. PowerBuilder es uno de ellos. En la nueva release 1.5 se ha probado y adaptado el plugin SCC para lograr compatibilidad total con PowerBuilder.
• Integración con CruiseControl: La nueva release 1.5 de Plastic se integra con la versión 2.7 de CruiseControl permitiendo a los usuarios automatizar tareas de compilación tanto desde Java como .NET.
• Integración con JDeveloper: La versión 1.5 de Plastic incorpora integración con JDeveloper. Ahora tanto JDeveloper como Eclipse están totalmente integrados con Plastic, facilitando el uso de la herramienta y mejorando la productividad de los desarrolladores.
• Mejoras en el instalador de Linux: La versión 1.5 incluye mejoras en el instalador de Linux. A partir de ahora instalar y poner en marcha Plastic con sistemas con Ubuntu, Suse y Fedora es aún mucho más sencillo.

¡Esperamos que os guste!

El equipo de Códice Software

Mejoras en el sistema de merge (usabilidad, Cherry Picking,...)

18:15 1 Comments

En las últimas releases se ha trabajado en mejorar el sistema de merge. Se ha buscado que sea más rápido, más efectivo y que de más información útil para el usuario (que contribuidor/es lo ha modificado, porque se ha descartado), siempre hay que mejorar, uno no se puede quedar estancado.

Pero no solo hay que mejorar las cosas, sino cambiarlas, adaptarlas. Tras observar la diversidad de patrones de SCM aplicados durante el desarrollo, se ha optado por ampliar las posibilidades de merge y de esta manera facilitar o tratar de ayudar en un patrón distinto al de rama por tarea que se propone.

Hasta ahora el comando de merge permitía incorporar los cambios realizados en una rama en el espacio de trabajo. A la hora de hacerlo se podía mezclar el último contenido de la rama o bien el contenido de la rama que hubiese sido etiquetado. Todo ello estaba orientado a facilitar el trabajo cuando se usaba el patrón de rama por tarea. A partir de ahora como origen del merge también se podrá elegir un changeset, una etiqueta o una revisión concreta.

Con todo, la forma de entender el merge como la mezcla del contenido del origen con el contenido del destino seguía siendo la misma. Para tratar de dar un mayor número de posibilidades se introdujo la posibilidad de realizar el merge no sólo con el contenido de la revisión, sino que también hacerlo con el cambio concreto introducido en una revisión (cherry picking) o de los cambios introducidos por un intervalo de revisiones.

El cherry picking es un merge mediante el cual un cambio (delta) introducido por una revisión es aplicado en el espacio de trabajo. Aunque está operación no suele ser muy común, dado que normalmente lo que se quiere es incorporar todo el contenido (la suma de todos los cambios que sufrió el origen), aunque en ocasiones incorporar sólo el último cambio puede resultar de utilidad.

Pongamos un escenario donde el cherry picking puede ser de gran utilidad. En una rama se está añadiendo nueva funcionalidad y durante el proceso se ha corregido un error, puede darse el caso de queramos incorporar esa corrección de error pero no la nueva funcionalidad en ese caso se usuaria el cherry picking.

Concretando tenemos una clase en la que hemos añadido varias propiedades y métodos, y posteriormente hemos corregido un pequeño error. Cuando se haga el cherry picking de la revisión (o changeset) que corrige el error como resultado se incluirá la corrección de ese error pero no la funcionalidad que había sido añadida previamente, la cual puede estar incompleta, sin probar, etc.

El caso de hacer el merge de un intervalo de revisiones extiende el concepto del cherry picking permitiendo incluir no sólo un cambio sino todos los cambios que se han realizado entre dos revisiones de un mismo elemento.

Aun así para realizar todas esto es más aconsejable crear una rama nueva que permita aislar el cambio tranquilamente de forma que la trazabilidad del mismo y su aislamiento sea mayor. Pero en caso de no querer realizar ramas para este tipo de cosas el cherry picking puede ser de gran utilidad.

SQL Server Intercalaciones (Collation)

19:14 3 Comments

Está palabra tan enrevesada es la empleada por Microsoft para definir como se ordenan y comparan las cadenas en los diferentes idiomas. Este punto, por el que se suele pasar muy por encima, es muy importante si se pretende usar SQL Server como backend en una aplicación con soporte para todos los idiomas (al menos en la información que se guarda como es nuestro caso).

El saber que palabra es igual a otra, o cual va antes que otra (alfabéticamente) puede parecer una cosa sin importancia y bastante trivial, en nuestro caso puede ser, pero en el resto de los idiomas no es así. Por ejemplo el Japonés emplea tres alfabetos diferentes, y tiene unas reglas bastante complejas para determinar que carácter va antes y cual después. Es más, inclusive dentro de un idioma como el nuestro existen diferentes criterios para ordenar como puede ser que la combinación de letras “ch” se coloque después de la letra c.

Las intercalaciones permiten definir el idioma, así como una serie de criterios adicionales que se aplican a la hora de diferenciar y ordenar diferentes caracteres. En SQL Server 2005 los idiomas soportados son los mismo que se soportan en los sistemas operativos Windows. Aparte del idioma entre los otros criterios que pueden especificarse son:

• Permite diferenciar entre mayúsculas y minúsculas (CS Case Sensitive – CI Case Insensitive).
• Permite diferenciar entre una misma letra acentuada o sin acentuar. (AS Accent Sensitive – AI Accent Insensitive).
• Permite diferenciar entre las sílabas japonesas katakana e hiragana (KS Kana Sensitive – KI Kana Insensitive).
• Permite distinguir la representación lógica de los caracteres para poder compararlos como iguales o diferentes desde su ancho (byte), sin importar que sean el mismo carácter (WS Width Sensitive – WI Width Insensitive).

La intercalación puede definirse a diferentes niveles según nos interese en cada caso. Puede definirse a nivel de servidor de BD, a nivel de la BD, a nivel del campo de texto dentro de la tabla o nivel de la consulta. Al margen del primer caso que es para tener una política general para todas ellas, las otras se aplicarían una u otra según nuestras necesidades:

• Si se aplica a nivel de BD no solamente los datos tendrán en cuenta estos criterios sino los nombres de tablas, campos,..
• Si se aplica a en los campos de texto dentro de las tablas lo podríamos hacer o para todos los datos o sólo para algunos, pero en cualquier caso los nombre de los elementos de la BD no se verían afectados.
• Si se aplica en las consultas, ese criterio sólo se aplicaría en esa consulta concreta, puede ser interesante para permitir hacer búsquedas al usuario sin tener que preocuparse de mayúsculas, acentos, etc, inclusive que el mismo lo defina en el momento de hacer la consulta (opciones de la búsqueda).

En cualquiera de los casos COLLATE seguido de la intercalación que se quiera utilizar.

Hemos sido galardonados en los premios AETICAL 07

8:52 2 Comments

El pasado viernes 4 la Federación de Asociaciones de Empresas de Tecnologías de la Información, Comunicación y Electrónica (AETICAL) celebró, en el Palacio de Saldañuela en Burgos, el VII Encuentro Regional de Empresas de Tecnologías de la Información. Durante el transcurso de este encuentro se dio lugar a la entrega de los Premios AETICAL 07.

Esta convocatoria, tiene como objeto premiar, a juicio de un jurado nombrado a tal efecto, por un lado, la empresa TIC más reconocida de la región durante el año 2006, por otro lado, el Proyecto TIC regional más innovador del pasado ejercicio y además reconocer el Apoyo a las Empresas de Tecnología de la Información, realizado en la Comunidad Autónoma de Castilla y León. Además de un premio de Honor a la persona, organización o institución qué por su trayectoria haya contribuido al desarrollo de la Sociedad de la Información y el conocimiento, la difusión, uso y divulgación de las Nuevas Tecnologías y sus aplicaciones.

Según el jurado, compuesto por representantes de la Administración regional, la Universidad, el mundo de la empresa, la plataforma sectorial y técnicos, a la empresa Códice Software S.L. se le han concedido 2 de estos galardones correspondientes a la empresa TIC más reconocida de la región en 2007 y al proyecto TIC regional más innovador han sido otorgados a esta empresa situada en el Parque Tecnológico de Boecillo.

Pablo Santos Luaces, Consejero Delegado de Códice Software, recibió de manos de Juan Posadas, vicepresidente de AETICAL, el premio a la empresa más reconocida, y Pedro Duque, astronauta de la Agencia Europea del Espacio, le hizo entrega del galardón al proyecto TIC más innovador.

CMMi Nivel 2

13:28 0 Comments

¡¡Ya es oficial!! El pasado 15 de Marzo Códice Software se convertía en la primera PYME española en lograr una certificación en CMMi, y hace tan sólo unas horas el SEI (Software Engineering Institute) acaba de publicar el resultado oficialmente.
Una de las características que hacen especial nuestra certificación es que utilizamos una metodología ágil denominada SCRUM, considerada por muchos incompatible con CMMi.
SCRUM se basa en dividir los proyectos en cortas iteraciones de un mes de máximo, y en cada una de ellas entregar funcionalidades completas. El control exhaustivo del avance, ejercido día a día, establece un mecanismo muy eficaz para reaccionar frente a posibles desviaciones, uno de los grandes problemas en los proyectos software. ¡¡Enhorabuena a todo el equipo por el éxito!!

BRITISH COMPUTER SOCIETY CONFIGURATION MANAGEMENT SPECIALIST GROUP

10:53 0 Comments

Estaremos presentes en la próxima conferencia del grupo de especialistas en gestión de la configuración de la British Computer Society, en Oxford, los días 15 y 16 de Mayo.

En esta ocasión hablaremos sobre las posibilidades que SCM introduce en la transición hacia técnicas ágiles, y más concretamente en lo que hemos denominado freeride development. El impacto de las metodologías ágiles en la gestión de configuración ha sido notable, fundamentalmente derivado de la introducción de la integración continua. Sin embargo el modo de aplicar dichas técnicas, derivado en muchas ocasiones del mundo del software libre, dista mucho de ser la más óptima, desperdiciando posibilidades y productividad que los sistemas SCM más avanzados proporcionan.

Plastic en Solaris 10 SPARC

10:40 0 Comments

Hoy he hecho un par de capturas de Plastic funcionando en nuestra máquina de pruebas Solaris 10 SPARC, una antigua SunBlade 1000 de unos 500 MB de RAM. La usamos semanalmente para realizar testing de LDAP y dentro de poco para integrarla dentro de los tests distribuidos PNUnit.


No es nada nuevo, porque la verdad es que desde el principio, y gracias a Mono, Plastic ha funcionado en Solaris. Hemos realizado diferentes pruebas tanto de cliente como de servidor, con éxito. Sin embargo de momento no hemos incluido Solaris como plataforma soportada oficialmente.

Nuestros planes de testing incluyen extender nuestros smoke tests, que actualmente realizamos sobre Windows y Linux (y combinando diferentes tipos de servidores y clientes), a:

• Solaris 10 SPARC
• MacOS X (mac-mini)
• Solaris 10 X86
• Nexenta

En cuanto a la release en Linux, tanto la parte servidor como línea de comandos siguen ahí, el problema es solucionar pequeñas incidencias como la implementación de WinForms de Mono, aunque precísamente esta semana compilaremos la última versión para comprobar si los fallos están resueltos.

Nuevas características del plugin para Eclipse

19:25 0 Comments

Esta semana hemos estado trabajando para ampliar y mejorar las características que ofrece la integración de PlasticSCM con el entorno de desarrollo Eclipse. Éstas son las nuevas características:

• Modificados los menus de team para mejorar la usabilidad.
• Añadida opción para ver diferencias con la versión anterior.
• Las diferencias y árbol de versiones se muestran en hilos independientes (anteriormente se quedaba sin pintar la ventana principal).
• Soporte para español
• Añadida una preferencia para hacer checkout automáticamente.
• Soporte para movidos, borrados y renombrados, tanto de ficheros como de directorios.
• Soporte para refactoring.

A continuación, se muestran algunas capturas:

Para modificar el idioma en el que se muestra el plugin:

Importador de CVS

18:39 0 Comments

Ya esta lista la primera versión del importador de CVS a Plastic. Hace toda la migración de un proyecto de CVS a un repositorio Plastic, lo cual incluye: etiquetas, ramas, revisiones (contenido, fecha, autor, comentarios y etiquetado).

Los mayores problemas han sido ser capaces de manejar las opciones menos comunes de CVS, como el cambio de numeración en una rama, el borrado de ramas dejando revisiones que no pertenecen a ninguna rama, etc.

Para el caso de las revisiones huerfanas de rama, no existe una correspondecia en Plastic, ya que en nuestro sistema toda revisión pertenece a una rama, no puede estar descolgada. En este caso se ha dispuesto un mecanismo para que estas revisiones se guarden en una especie de rama papelera, de modo que pueda accederse a sus comentarios, contenido, etc. manteniendo además sus relaciones con el resto de revisiones, igual que lo hacia en CVS.

Aquí os muestro un ejemplo de como queda el arbol de revisiones de un fichero en CVS y su correspondiente importación en Plastic:

¿Qué pasa cuándo necesito algo de otra tarea?

14:31 1 Comments

Los usuarios de Plastic SCM que han comenzado a usar el patrón de rama por tarea han visto enseguida la ventaja de poder aislar sus cambios, y sobretodo de poder elegir qué tareas se integran y que tareas quedan fuera en una release concreta.
Sin embargo, el concepto es mucho más sencillo de asimilar para antiguos usuarios de Clearcase (acostumbrados a los viejos config_specs los selectores les parecen sencillos...) que para ex-sufridores de SourceSafe. Para los segundos su ciclo habitual de trabajo era "necesito tu cambio, haz check-in y lo cojo para seguir ...". Simple, pero muy propenso a propagar errores, por no hablar de la imposibilidad de elegir qué se integra y qué no cuando todo está ya en la línea principal.
Se trata, no obstante, de algo totalmente normal. Cuando alguien trabaja sin control de versiones o con uno muy primitivo, está acostumbrado a tener que actualizar continuamente su copia de trabajo (en el mejor de los casos, cuando no la copia global de todo el equipo) para coger los cambios de los demás. El bloqueo mútuo es constante, y las ventajas de no estar limitado por él evidentes. Pero cambiar los hábitos cuesta trabajo.
Realmente tener que coger algo de una tarea de otro programador es algo que ocurre excepcionalmente, quizá inversamente proporcional al estado del desarrollo del proyecto (es decir, puede ocurrir más al principio y mucho menos en mantenimiento). La idea es que las tareas sean independientes entre sí siempre que se pueda (hasta que se llega a una release intermedia, que puede ocurrir cada día, una vez a la semana, etc, etc).
El problema es que los programadores que comienzan a usar el nuevo patrón de trabajo tienen una sensación de urgencia que les lleva a querer incorporar todo lo que hacen sus compañeros a la rama de su tarea actual. Se trata, como decía, de algo totalmente normal. De hecho, mirando alguno de nuestros árboles de versiones, de cuando comenzamos a usar Plastic para gestionar su propio desarrollo y alguno de los miembros del equipo pasaba por una fase similar, se puede apreciar perfectamente el patrón de merge excesivo entre ramas.

La imagen muestra uno de nuestros ficheros, en una fase muy inicial del desarrollo, y cómo se producen merges sucesivos entre dos ramas (de dos tareas diferentes).

En ocasiones es inevitable (y correcto) que esto ocurra, pero en otras no.
Veamos un ejemplo: la semana pasada estuve trabajando en dos tareas diferentes, por un lado la tarea SCM1457 en la que introduje unas modificaciones en la herramienta gráfica para que funcionase correctamente en Linux, por otro una mejora (SCM1461) que permite fijar el selector para trabajar en una rama o en una etiqueta sin tener que editarlo a mano, sólo con el menú contextual. Más tarde necesitaba grabar un vídeo del sistema funcionando en Linux, y pensé que estaría bien poder mostrar la nueva funcionalidad de cambio de selector. Así que había varias opciones:

• Integrar los cambios de SCM1457 sobre SCM1461 (o viceversa), compilar y grabar el vídeo. Es la opción más sencilla, pero no siempre la más adecuada. ¿Por qué? Supongamos que las correcciones para funcionar en Linux (SCM1457) se integran sobre SCM1461. ¿Qué pasa si posteriormente se descubre que esas correcciones no son correctas en Windows? La tarea 1461 queda afectada por esos cambios, y ya no se puede decidir integrar 1461 y excluir 1457 (como se haría en el escenario habitual), ya que 1461 incluye 1457.
• Crear una nueva rama e integrar ambas sobre ella. Es una opción adecuada, ya que evita los problemas de la aproximación anterior. No obstante en mi caso sólo necesitaba ambas tareas juntas para realizar una simple compilación, sin tener que esperar a la próxima release.
• Usar el selector para coger los contenidos de ambas ramas.

El tercer caso es el que finalmente utilicé, y el que voy a explicar. Observando los contenidos de ambas ramas se veía que no tocaban los mismos ficheros, así que era posible cargar ambos sin necesidad de hacer un merge. De hecho en la tarea para las correcciones en Linux sólo había modificado 2 ficheros, con cargarlos y coger también la rama 1461, sería suficiente.

repository "codice"
  // coger el fichero SeidUtils.cs y Optionsform.cs de 1467
  path "/01nerva/src/client/security/linuxseid/SeidUtils.cs"
    br "/main/FixBL047/SCM1457"
  path "/01nerva/src/plastic/OptionsForm.cs"
    br "/main/FixBL047/SCM1457"
  // el resto de 1461
  path "/"       
    br "/main/FixBL047/SCM1461" lb "BL047.5"

De este modo, sin necesidad de hacer un merge,
se pueden cargar contenidos de más de una ubicación.

Una demostración más de la potencia de los selectores.

Integración de Visual Studio y Plastic SCM

10:07 0 Comments

Todos los que han usado Visual Studio 2003 con algún control de versiones sabrán que no está preparado para soportar movidos y renombrados de elementos. Se trata de una limitación heredada de Visual Source Safe, que no controla versiones de directorios, y por tanto tiene graves problemas tanto moviendo como renombrando ficheros.

Sin embargo, en la versión 2005, el IDE si soporta esta funcionalidad, informando al control de código fuente que tenga por debajo de los elementos movidos renombrados desde Visual Studio.

A partir de la versión 47.5, los usuarios de Plastic podrán disfrutar de esta funcionalidad, que la mayoría de controles de versiones no soportan en su integración con Visual Studio: sólo teneis que echar un vistazo a Perforce, SurroundSCM, AccuRev, Hansky ...

En versiones posteriores, iremos mejorando las posibilidades para que el trabajo con PlasticSCM desde los entornos de desarrollo sean completamente funcionales.

Por otro lado, se ha dado soporte para integrar PlasticSCM con MSAccess. Tan sólo hay que instalar un Add-in proporcionado por Microsoft, e instalar el Plugin de Visual Studio de Plastic.

Se acerca la versión Linux de PlasticSCM ...

14:12 0 Comments

Hemos estado trabajando estas últimas semanas para sacar una release de nuestro producto en Linux. Estamos terminando los últimos detalles para que esté todo listo. Nos gustaría agradecer a nuestros colegas de Mono y Bitrock, el trabajo realizado, ya que sin su ayuda no hubiera sido posible.

Uno de los puntos fuertes de nuestra herramienta, es la facilidad de instalación. Hemos querido mantener esta característica en sistemas Linux. Tanto la instalación como la configuración de la herramienta se puede realizar en modo gráfico o en modo texto. A continuación mostramos unas capturas de pantalla:

Esta es la instalación en modo gráfico:

Esta es la instalación en modo texto:

Y esta es la configuración de los clientes en modo texto:

El instalador también posee un modo desatendido, con el que se pueden realizar instalaciones en múltiples máquinas sin la intervención del usuario. De esta forma se ahorrará un gran trabajo a los administradores que tengan que instalar un número elevado de copias en varios ordenadores.

Artículo en "Sólo programadores"

13:41 0 Comments

Podeis encontrar un artículo publicado en la última edición de la revista "Sólo programadores", se trata del primero de una serie de artículos para introduciros en las herramientas de control de versiones o SCM. Se explican las funcionalidades de este tipo de herramientas, los distintos elementos que las componen y las ventajas de su uso, cada vez más extendido en los entornos de programación.