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:

Cambios de tarea

17:09 0 Comments

Los cambios de tarea son muy malos para la productividad. No importa quién hable de ello, está claro que cambiar a alguien de tarea es un gasto de tiempo que, a pesar de todo, siempre ocurre en los desarrollos de software.
Recuerdo que en el libro Peopleware, hay un capítulo que habla de la enorme cantidad de tiempo desperdiciada cambiando de tarea. Hace poco (y es por eso que estoy escribiendo) leí una entrada en el blog JoelOnSoftware tratando sobre lo mismo. Pero como Joel decia: no siempre se pueden evitar los cambios de tarea.

Así que, cambiar de una tarea a otra porque aparece algún problema urgente, una petición de cliente o algo similar parece inevitable... y el impacto en productividad muy alto pero... ¿hay alguna manera de minimizarlo?

Si eres un programador trabajando en cierto código y te ves forzado a cambiar a otra cosa, ¿cómo lo harías? Normamente habrá unos cuantos ficheros en los que estás trabajando, y muy probablemente todavía no hayas acabado. Entonces, ¿qué haces con el trabajo que todavía no está terminado? Probablemente estés usando algún tipo de control de versiones, pero hacer un commit o una protección (un checkin) de código a medio acabar no parece muy buena idea. ¿Qué hacer entonces? Probablemente acabarás copiando los ficheros a otro directorio, y preparando el área de trabajo para la siguiente tarea.

La imagen muestra la situación. Incluso teniendo un control de versiones, el programador acaba copiando ficheros manualmente. No tiene muy buena pinta. Además, todos esos cambios se quedan fuera del control de versiones y... ¿por cuánto tiempo?



¿Qué puede ocurrir con esos cambios si se quedan fuera del control de versiones? ¿Pueden perderse? ¿Qué pasa si se tarda más en volver a la tarea de lo esperado? ¿Y si se rompe el ordenador del programador? :-)

La mayoría de los controles de versiones fuerzan a seguir un modelo como el ilustrado en la imagen. Vale, no todos ellos, y por eso estoy escribiendo sobre el tema...

¿No sería mejor que el control de versiones ayudara a gestionar los cambios de tarea?Se puede hacer mediante el patrón de rama por tarea. Creas una rama cada vez que tienes que trabajar en algo, sea lo que sea, desde un pequeño cambio hasta una tarea de varias semanas de trabajo. Entonces, teniendo tu propia rama, puedes proteger tus cambios (quiero decir hacer checkin en el control de versiones) tantas veces como necesites.
Se guardarán los cambios intermedios, todo el trabajo del desarrollador se almacena en el servidor (puedes incluso evitar los backups de las máquinas de los desarrolladores, ahorrando dinero), así que nunca más te pasará eso de sí, creo que el código bueno estaba en tu ordenador.

Y además ayuda a cambiar de tarea: haces check in de todo, enviándolo a la rama asociada a la tarea, y símplemente te mueves a la nueva. Nada de copiar ficheros a mano, nada de riesgos extra, nada de tiempo perdido. Símplemente usar la herramienta.



Entonces, si es tan fácil... ¿por qué no es lo que hace todo el mundo? ¡¡Límites!! La mayoría de los controles de versiones tienen graves problemas trabajando con ramas, por eso no puedes plantearte usar rama por tarea, y cambiar de tarea es un dolor. Y por eso hemos diseñado Plastic SCM para que trabaje perfectamente con ramas. Puedes seguir la estrategia que hemos propuesto con nuestra herramienta... ¡¡y verás la diferencia!! :-P

0 comentarios:

Redepyme 2006

13:37 0 Comments

Estamos presentes en la XI edición de Redepyme, en el Recinto Ferial Juan Carlos I, en Madrid.
Durante los días 30 de Noviembre y 1 de Diciembre presentamos nuestro sistema, Plastic SCM, a los asistentes al evento.



0 comentarios:

Curso SCM en la Universidad de Valladolid

0:01 0 Comments

Durante los días 29 y 30 de Noviembre se impartirá un curso de SCM para los alumnos de la Universidad de Valladolid en el Campus Miguel Delibes.
El curso, orientado a los alumnos de Ingeniería de Telecomunicación y de Ingeniería en Informática, introducirá a los asistentes en la disciplina de Gestión de la Configuración, desde los conceptos más básicos hasta los más avanzados, pasando por la presentación de diferentes patrones.

0 comentarios:

Merge de documentos de Word

19:26 0 Comments

Un SCM no es sólo para gestionar código fuente. De hecho lo más importante de Plastic es que puede usarse para controlar todos los elementos de un proyecto: imágenes, código fuente, binarios y... documentos!
En todo desarrollo se manejan documentos: análisis, diseño, requisitos, caso de prueba, planificaciones, plantillas... y mucho más si se sigue (o se está intentando obtener) algún tipo de certificación como ISO o CMMi.
El siguiente vídeo muestra cómo hacer cambios en paralelo sobre un documento de Microsoft Word, y cómo reconciliar las modificaciones automáticamente. También cómo visualizar las diferencias.

0 comentarios:

Tech Ed 2006

12:33 0 Comments

Durante la segunda semana de Noviembre (del 8 al 11) se celebró en Barcelona Tech Ed Developers 2006, el encuentro más importante de desarrolladores con tecnologías Microsoft a nivel europeo.
Como habíamos anunciado con anterioridad, estuvimos presentes con un stand, una oportunidad única para dar a conocer Plastic SCM a nivel internacional.

Durante los 4 días de duración del evento se sucedían intensas jornadas de formación (conferencias, talleres, presentaciones), con intervalos de descanso que los asistentes aprovechaban para visitar los stands.
Pudimos comprobar que de las más de 50 empresas presentes en el área de exhibición, éramos la única compañía española.
Uno de los aspectos que más nos llamó la atención fue la presencia de multitud miembros de equipos de desarrollo de Microsoft tales como Visual Studio, Office o PowerShell. Tuvimos la oportunidad de hablar con muchos de ellos, intercambiando ideas y opiniones sobre Plastic.

0 comentarios:

SIMO 2006

12:26 0 Comments

Nuestra presentación oficial a nivel nacional tuvo lugar en SIMO 2006, en IFEMA, la semana del 8 de Noviembre.
Nuestro stand principal estaba en el pabellón 4, en el área de empresas de Excal, junto a otras empresas de Castilla y León. Tuvimos la oportunidad de presentar Plastic SCM a multitud de empresas que se acercaron a visitarnos.

Pero nuestra presencia en SIMO no se limitó a ese stand: fuimos seleccionados por la iniciativa Vivero de Empresas y contamos con un segundo stand en el pabellón 1, junto con otras empresas innovadoras de muy reciente creación.
A pesar de la clara generalización de SIMO en las últimas ediciones, que se aleja cada vez más de la orientación estrictamente profesional con que contaba inicialmente, la feria ha sido muy positiva para nosotros, y un escaparate magnífico para presentar nuestro producto.

0 comentarios:

Hoy hace un año...

11:34 0 Comments

Este mismo día hace un año Daniel y yo comenzábamos nuestra andadura aquí. Era una nueva empresa, un nuevo proyecto, una nueva metodología, un nuevo reto.

Cuando llegamos el grupo era pequeño (con tan solo cuatro miembros), el ambiente era muy bueno y todos trabajamos como un equipo, codo con codo. Poco a poco, el equipo fue creciendo poco a poco, hasta el de hoy, el que aparece en la foto, el cual esperamos que continúe creciendo.



En todo este tiempo, hemos podido ver como el proyecto iba creciendo, y poco a poco iba cumpliendo con nuestras expectativas. Ya desde hace más de seis meses que comenzamos a usarlo para nuestro propio desarrollo. En un primer momento, todo eran miedos y dificultades; había que tener mucho cuidado de que nada se hubiese roto y hubiésemos perdido algo, pero esa sensación duró muy poco, pues pronto el núcleo del sistema demostró ser muy estable. Esta forma de trabajo nos permitió ir encontrando nuestros propios errores, así como ver cuales eran las necesidades de un usuario. Gracias a este sufrimiento ayer pudimos colgar un producto en la web, del que todos nos sentimos muy orgullosos y que ha cumplido con creces nuestras expectativas.

Pero no por ello hemos acabado, aun tenemos que seguir mejorando y seguir mejorando el producto, cosa que por supuesto iremos haciendo.

0 comentarios:

Firebird y las transacciones "Repeateable read"

10:08 0 Comments

Una caracteristica de las transacciones es el aislamiento entre ellas. Según esto una transacción de no deberia interferir con las demás, pero a fin de evitar la total serialización se ofrecen varios niveles de aislamiento, cada una con un balance diferente entre aislamiento y rendimiento.

El nivel "Repeateable read" es uno de ellos, su mecanismo es el siguiente: Al iniciar una transacción se captura el estado actual de la base de datos y se trabaja sobre este.

Este nivel ofrece una buena relación entre aislamiento y rendimiento, pero hay que tener en cuenta algo muy importante: si se inicia una transacción cuando otra ha realizado un update sobre algun de elemento, sin haber realizado el commit, en ese caso cualquier operacion de update sobre ese elemento antes de que la otra transacción haga el commit provocará un deadlock.

0 comentarios:

Códice Software colabora en el Master Internacional en Ingeniería del Software

19:04 0 Comments

La Universidad de Castilla la Mancha y la Oficina de Colaboración Universitaria (OCU), organizan un Master Internacional en Ingeniería de Software, con el objetivo de aumentar el número de profesionales capacitados para dirigir y gestionar proyectos software.
Códice Software participa como colaborador, impartiendo formación sobre lo que mejor sabemos hacer: gestión de configuración de software.

0 comentarios:

Ferias SIMO y Tech-Ed

13:28 0 Comments

Códice Software presentará su herramienta Plastic para la Gestión de Configuración de Software en la próxima edición del SIMO, que tendrá lugar en el pabellón Ifema del 7 al 12 de Noviembre, nos pueden encontrar en el pabellón 1 stand 1C315 y en el pabellón 4 stand 4F607.
De manera simultánea, del 7 al 10 de noviembre participaremos como única empresa española seleccionada en la feria organizada por Microsoft: "Tech-Ed Developers" (www.microsoft.com/europe/teched-developers) que tendrá lugar en el Centro Internacional de Convenciones de Barcelona, estaremos esperándoles en el stand C23.

0 comentarios:

El atributo STAThread y el Garbage Collector

17:09 1 Comments

Hace unos días nos dimos cuenta de que nuestro servidor ocupaba mucha más memoria que unas releases atrás. Despues de varios días de ardua investigación nos dimos cuenta de que el problema venía porque se había añadido por error el atributo STAThread al metodo main de nuestro servidor.

Razón: parece ser que el framework tiene algún problema a la hora de liberar la memoria cuando se utiliza este atributo, de modo que permanecían en memoria multitud de SQLConnections con sus respectivos Strings, RegularExpressions, etc.

Solución: en nuestro caso tan fácil como quitar ese atributo ;-) pero si es necesario trabajar con el, podría llamarse a la función GC.GetTotalMemory(true), y así el Garbage Collector sería capaz de liberar la memoria sin ningún problema. Ojo, no usar el clásico GC.Collect() porque en este caso no sirve de nada.

1 comentarios:

Plastic en navegapolis

23:39 0 Comments

Juan Palacio ha incluido una entrada en el blog de navegapolis sobre nuestro proyecto, hablando sobre cómo hemos aplicado SCRUM para el desarrollo.
Nos decidimos por SCRUM porque se adapta muy bien a nuestro modo de trabajar, y de hecho es lo que estamos usando para evaluarnos en CMMi nivel 2 (esperemos que a final de año).
Nos parece muy interesante la posibilidad de ir difundiendo SCRUM en España, e ir compartiendo experiencias en ese área.
¡¡Gracias Juan!!

0 comentarios:

Mono

2:00 0 Comments

La semana pasada intercambiamos algunos correos con Miguel de Icaza, hablando sobre cómo nuestro sistema funciona en Unix sobre Mono, y sobre algunos problemas que tenemos con la interfaz gráfica.

Desde entonces hemos aparecido en: su blog, en la página de Mono con pnunit, y en la lista de empresas que usan mono.

Y, ni que decir tiene que cuando vimos nuestras capturas en el blog de Icaza algunos casi nos ponemos a dar botes... :-)

0 comentarios:

Superamos las 100mil líneas de código

11:55 0 Comments

Hace ya algunas releases (creamos una cada semana para ir midiendo nuestro progreso), superamos las 100mil líneas de código. Casi todo el proyecto está escrito en C#, aunque también tenemos algo de código en Java y C++.

0 comentarios:

Estaremos en Tech-Ed Developers 2006

11:06 0 Comments

Microsoft ha confirmado nuestra presencia en Tech-Ed Developers 2006, en la que presentaremos nuestro producto del 7 al 10 de Noviembre.
Tech-Ed Developers es uno de los eventos más importantes para desarrolladores con tecnología Microsoft, y para nosotros una de las primeras grandes citas para mostrar nuestro sistema.
En Tech-Ed presentaremos una versión de nuestro sistema ejecutándose sobre .NET 2.0 y utilizando como back-end SQL Server 2005. El servidor puede trabajar contra diferentes bases de datos, pero para Tech-Ed lo más apropiado será SQLServer :-)

0 comentarios:

Más rápido que Perforce!!

12:37 0 Comments


Perforce es el SCM más rápido del mercado... ¡de momento! El viernes estuvimos comparando nuestra velocidad (BL035) contra la suya y... ¡somos más rápidos en el update!
Es sólo un comienzo, claro, porque Perforce sigue siendo más rápido en todo lo demás (add, check in, check out... add sobretodo), pero el update suele ser una de las operaciones más utilizadas, y que más tiempo lleva.

Probamos ambos sistemas en las mismas condiciones, y con un repositorio de unos 183Mb y 2426 elementos (entre ficheros y directorios). ¿Los resultados? Plastic necesita 52 segundos para hacer un update forzado (escribe todo) mientras que Perforce tarda 58 segundos. Repetimos las mediciones varias veces para estar seguros... :-)

No es una gran diferencia, pero nos ha servido para comprobar que estamos en el buen camino en cuanto a rendimiento.

0 comentarios:

Hablando sobre SCM en DDJ

0:32 0 Comments

Hace unos días publicaron en DDJ un artículo que escribí hace ya más de un año hablando sobre SCM en pequeñas empresas. Habla de mis experiencias con el SCM en la empresa anterior en la que estuve trabajando, en la que se dedican a los sistemas ERP.
Por aquel entonces ya estaba muy centrado en la gestión de configuración de software, de hecho creo que ya estábamos pensando en comenzar con esta empresa.
El primer objetivo que tenemos en Códice Software es precísamente crear un producto que permita solucionar sus problemas de SCM a cualquier tipo de empresa, y a un precio asequible. Bueno, precísamente tratando algunos de los puntos que se mencionan en el artículo.

0 comentarios:

Plastic en español

10:36 0 Comments

Ya está disponible la primera traducción de Plastic a otros idiomas. Hemos comenzado por el español. Aquí se puede ver una captura ...
Próximamente se irá traduciendo a otros idiomas ... francés, alemán, chino ...

0 comentarios:

Cambios en la detección del merge

17:16 0 Comments

Esto días hemos estado modificando el sistema de detección de merges.

La dificultad se presenta al no saber como quedará el contenido de un directorio hasta que no se haga el merge del mismo. Esto es así porque un fichero que ha sido modificado puede haber sido borrado posteriormente, con lo que ya no se vería y no sería necesario hacerle el merge.

A esto hay que añadir que es necesario diferenciar cuando un elemento se añade o cuando estaba añadido y se borró, en cuyo caso ya no sería necesario volver a añadirlo.

Debido a esta problemática, la mayoría de los sistemas de SCM no muestran los elementos de los que va a ser necesario hacer el merge. Incluso algunos en los que si lo muestran como es el caso de ClearCase si en un merge hay involucrados directorios avisa de que hasta que no se resuelva esos directorios no se verá lo que hay que hacer con sus contenidos.

Al final se han conseguido filtrar los borrados en prácticamente la totalidad de los casos y para estos casos en los que no es posible se avisa cuando se va a hacer el merge de ese elemento que ya no esta y se descarta su merge.

0 comentarios:

Nuevas funcionalidades en el árbol de versiones

8:28 0 Comments


Por fin hemos tenido algo de tiempo

para actualizar el árbol de versiones. Lleva funcionando unos cuantos meses, pero no habíamos planificado ninguna tarea para ir actualizando un poco la interfaz. Hace un par de días David le añadió la capacidad de invocar a la herramienta de diferencias. Es posible marcar un par de revisiones y ver las diferencias entre ellas.

El objetivo es que al final pueda hacer todo lo que se hace desde la herramienta gráfica relativo a revisiones... poco a poco.

Estaría bien que también se pudiera lanzar el merge desde aquí, muy útil en algunas ocasiones.

0 comentarios:

Estuvimos en Sólo Pruebas 2006

23:29 0 Comments

El viernes pasado estuvimos en Sólo Pruebas 2006.
http://www.calidaddelsoftware.com/modules.php?name=News&file=article&sid=158

Presentamos la extensión de NUnit que hemos desarrollado, y que nos permite ejecutar tests unitarios sobre múltiples máquinas, distribuyendo las pruebas y creando diferentes escenarios Linux/Windows (mono/.NET).

Esperamos hacer la plataforma open source lo antes posible...

0 comentarios:

Unas cuantas estadísticas

13:56 0 Comments


Después de unos cuántos meses de desarrollo hemos sacado algunos datos del SCM.
Hay alguna información interesante, que además encaja a la perfección con lo que se suele manejar en los libros.
Por ejemplo, puede verse cláramente que poco más de un 20% de los ficheros (elementos) tiene alrededor de un 80% de los cambios (revisiones). A partir de ahí el 80% restante aporta sólo un 20% de los cambios. Es decir, hay unos pocos ficheros y directorios que reciben todos los cambios, mientras que el resto se mantiene más o menos estable.
El siguiente gráfico continúa explicando más o menos lo mismo.

El 57% de los elementos dentro del sistema (ficheros y directorios), tienen sólo una revisión. Puede verse fácilmente que la mayoría de los elementos tienen bastante pocos cambios, sin embargo hay unos pocos que hay que tocar siempre...

0 comentarios:

Actulizando la interfaz de merge

13:51 0 Comments

Poco a poco vamos cambiando la herramienta de merge, en un intento por facilitar la tarea al usuario y seguir el estilo del resto de las herramientas del producto. Al ser antes muy diferente a todas las demás herramientas.


Aunque ahora es más fácil de usar y más amigable que antes, seguimos teniendo un algunas dificultades para encontrar una combinación de colores que resulte más agradable al usario.




0 comentarios:

Nuevo comando DiffMetrics

11:06 0 Comments

Este comando permite saber cuantos cambios hay entre un par de ficheros, así como el tipo de los mismos. Nos permite conocer entre dos ficheros (o revisiones) cuantas líneas han sido eliminadas, añadidas y modificadas.

En este caso no interesa saber cuales son los cambios, para obtener una estadista o métrica sobre los mismo. Y no tanto el cambio en concreto, más necesario en integraciones y durante el desarrollo.

Este tipo de estadísticas permite conocer el volumen de cambios en un fichero. Pudiendo sacar una idea clara de cuales son las partes del proyecto sobre las que más se trabaja y las que se modifican muy frecuentemente pero de forma muy localizada.

Es importante conocer el tipo de cambios que se realizán, pues nos da una idea del estado del proyecto (entre otras cosas). Así un gran numero de líneas añadidas es indicativo de un proyecto al inicio de su desarrollo, en el que se añade gran cantidad de nueva funcionalidad. En cambio en un proyecto durante sus últimas fases predominará, las líneas modificadas frente a los demás cambios, caso típico de correcciones y optimizaciones. Mientras que un número elevado de líneas borradas es significativo de una limpieza de código tras una revisión de código.

0 comentarios:

Nuevo diálogo para mostrar diferencias

10:59 0 Comments


Se ha creado un nuevo diálogo para mostrar diferencias. El anterior sólamente permitía mostrar diferencias entre dos revisiones de un item. Ver captura:

El nuevo diálogo permite invocar a la herramienta de diferencias de forma mucho mas potente. Se pueden ver diferencias entre revisiones de dos items distintos, o entre un fichero privado y un ítem.

Para ítems, se puede especificar la revisión que hay en el Workspace (es decir, en disco), la última reivisón en una rama determinada o seleccionar una revisión cualquiera de su 'revision history'. Además, para la selección de ítem, para la selección de rama y para la selección de revisión, se ha hecho exploradores de elementos para facilitar la búsqueda de éstos. Ver captura:


0 comentarios:

Búsquedas en GUI

9:35 0 Comments

Se han introducido las búsquedas dentro de la herramienta gráfica. Permitiendo encontrar los checkouts del workspace actual o la de todos los usuarios, así como los elementos privados dentro del workspace o los que han sido modificados manualmente sin hacer un checkout.

0 comentarios:

Criterios de ordenación

9:31 0 Comments

Se cambian los criterios de ordenacion en la herramienta gráfica para que no solo se base en el texto sino en criterios más manejables para cada elemento.

Así las fechas quedarán ordenadas de forma temporal en vez de textual.

La ordenacion de lo elementos se parece más a la de un sistema de ficheros quedando antes los directorios que los ficheros y a su vez dentro de estos los controlados quedarán antes que los privados. Manteniendose en todo momento la ordenación por nombre dentro de ellos.



También se ha evitado los problemas que genera la ordenación textual con los numeros al colocar esta el 18 antes que el 2.

0 comentarios:

Plugin para eclipse, funcionando en Linux.

16:25 0 Comments

Ya tenemos plugin para desarrollar con el eclipse en Linux. Ahora su comportamiento y funcionalidad son los mismos que en Windows, no sin antes haber resuelto algunos problemas de compatibilidad.

0 comentarios:

Nuevo asistente de configuración

18:53 0 Comments


Hemos creado un nuevo asistente de configuración que facilita establecer los parámetros en el fichero client.conf de la herramienta, de forma correcta. De esta forma se evitan posibles errores de funcionamiento provocados por una configuración errónea.





Con el asistente se puede configurar:

  • El idioma
  • El modo de configuración del sistema de usuarios/seguridad
  • Parámetros de configuración del directorio activo (si lo hay)
  • Servidor de workspaces
  • Repositorio por defecto

0 comentarios:

Ejecutando el GUI en Mono

11:33 0 Comments

Hemos vuelto a probar la herramienta GUI sobre mono, pero esta vez usando la 1.1.15 en Linux. Está claro que han hecho un gran trabajo, porque sin haber hecho ningún cambio a nuestra aplicación, ahora se ve mucho mejor! :-)


















Todavía estamos un poco lejos del aspecto en Windows, pero parece claro que en poco tiempo (quizá lo que ahora se ve mal pueda arreglarse con algunos cambios en nuestro código) la herramienta funcionará igual sobre .NET y sobre mono.

De hecho la misma aplicación con la versión 1.1.13-2 de mono estaba bastante lejos de lo que se puede ver en la 1.1.15.



















Las transparencias de los paneles no se dibujaban correctamente, lo que justifica las manchas negras por casi todos lados. Uno de nuestros principales objetivos es que todo el sistema (tanto cliente como servidor) puedan ser multiplataforma, y hasta ahora, gracias a mono, lo estamos consiguiendo. Por último una imagen parecida de la herramienta gráfica, pero esta vez en Windows XP. Sin duda el aspecto es mejor, pero esperemos que la "ventaja" no dure mucho... ;-)


0 comentarios:

Nuevo aspecto de la herramienta gráfica

11:05 0 Comments

Seguimos haciendo cambios sobre la herramienta gráfica. La versión Alpha muy probablemente tendrá el aspecto que muestra la imagen, que es una versión simplificada de ribbon.

0 comentarios:

Sistema de control múltiple de VNC's

9:30 0 Comments

Ha llegado la hora de probar con varias máquinas virtuales montadas sobre diferentes sistemas, y es ahora cuando puede sacarse mayor partido a nuestro sistema de control múltiple de VNC's.

Desarrollado en .NET este sistema nos permite tener el control simultaneo de varios VNC's en una misma aplicación de modo que con un simple movimiento de ratón pasamos de controlar un máquina a controlar otra distinta, con independencia de que esta sea un sistema Linux o Windows.


0 comentarios:

Unos cuantos gráficos más

21:17 0 Comments


Bueno, después de los escenarios de merge que creamos la semana pasada teníamos ganas de ver qué pinta tendrían en nuestra herramienta.

Y aquí están. Es todavía una versión primitiva pero suficiente para irse haciendo una idea. Quizá el árbol es demasiado complicado para ser dibujado en 3D.

0 comentarios:

Merges de pesadilla

0:09 0 Comments


Ayer estuvimos trabajando en algunas mejoras en el sistema de merge. Borja ha preparado algunos casos de prueba bastante complicados.

La imagen muestra un árbol de versiones bastante complejo, que incluye multitud de casos diferentes de merge.


Ahora podemos tratar correctamente varios links de merge hacia una misma revisión, resolviendo correctamente el antecesor común. Hasta ahora teníamos ya en marcha parte del sistema, pero con algunos problemas que han quedado resueltos.

0 comentarios: