4 reglas para tu proceso de control de versiones

9:46 0 Comments

Al principio todo era plano.



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



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

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

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

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

Que yo traduzco por:

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

Y la diapositiva 20 dónde menciona:

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

Que viene a ser:

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

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

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

Menciona lo siguiente en la diapositiva 26:

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

Esto también parece interesante, ¿no?

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

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

Las reglas

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

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

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

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


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

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




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

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

Llega una nueva era... ¡preparate!

Herramienta de Xmerge para gestionar refactors

13:27 0 Comments

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

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

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

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



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

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





¿Qué pasará al intentar integrar los cambios?

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



¿Y si la herramienta pudiera ayudar?

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

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

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



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

Fácil, ¿no?

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



¿Los siguientes pasos?

Estos son algunos:

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

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

Búsqueda de código movido en ficheros

¡Estad atentos!

Como utilizar Plastic SCM y DevTrack parte I

11:02 0 Comments

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

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

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

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


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


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

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

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

¡Así de sencillo!

Repositorio de Mono en Plastic

14:37 1 Comments

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

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

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




Ramas:



Un árbol de versiones del directorio de Mono:



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


El explorador de ramas...



Y la vista de contenido de una rama:



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

Como configurar MySQL como backend en Plastic SCM 2.5

13:23 3 Comments

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

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

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

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

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

Cómo utilizar Plastic SCM y Bugzilla II

10:13 0 Comments

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

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

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

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

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

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

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

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

¡Espero que os guste!

Cómo utilizar Plastic SCM y Bugzilla I

10:10 0 Comments

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

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


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

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

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

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

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

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


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


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


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

¡Simple e intuitivo…que lo disfrutéis!

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

9:16 0 Comments

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

Esta nueva versión incluye:

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



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



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



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



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



• Correción de errores.

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

Problemas de usuarios

14:15 0 Comments

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

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



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

¡Gracias por la estupenda referencia Jonathan!

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

El modo desconectado de Visual Studio

11:21 0 Comments

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

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

O como ésta si estamos trabajando con Visual Studio2005:

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

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

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

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

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

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

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

Algunos problemas conocidos

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

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

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





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

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

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

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

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

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


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

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

En Visual Studio 2005 este problema está corregido.

Ramas e integraciones con Delphi parte II

14:56 0 Comments

En la primera parte hablamos de la parte más básica de utilizar the Plastic SCM con Delphi. Ahora nos vamos a centrar en cómo gestionar las ramas y las integraciones y en cómo Plastic maneja el código fuente de Delphi.

Creación de ramas

Mi patrón de ramas preferido utilizando Plastic SCM es el de rama por tarea así que es lo que voy a hacer ahora: crearé un par de ramas y trabajaré en paralelo modificando el mismo código de manera diferente como harían dos desarrolladores. No me importa dónde hago los cambios y dejo que Plastic reconcilie los cambios una vez que haya terminado, para eso están la gestión de ramas y las integraciones, ¿no?.

¿Qué hay que hacer para crear una nueva rama en Plastic? Muy fácil: no tiene nada que ver con los comandos antiguos de copiar o instrucciones raras (bueno, se puede escribir cm mkbr si te gusta trabajar en línea de comandos, por supuesto), simplemente tienes que ir al explorador de ramas, hacer botón derecho en la rama desde la que se quiera crear una nueva y seleccionar "crear rama hija". Entonces saldrá el diálogo de crear una rama intelignete:



¿Qué es una rama inteligente? Pues es simplemente una rama que es capaz de recordar su punto de partida. Para explicarlo de manera simple; se le dice a la rama dónde están las fuentes que se quieren modificar y más adelante se puede modificar esta localización. En mi ejemplo le dije a Plastic que creara una rama denominada task001 que partiese de la etiqueta que había creado anteriormente: initial_version.

Nota: no, no es necesario escribir guión bajo en vez de espacios en los nombres de las etiquetas, se podría escribir una versión inicial y sería un nombre de etiqueta válido, pero habiendo utilizado el viejo DOS durante años no te acostumbras a que pueda funcionar realmente... ;-)

Después de crear la nueva rama, puedes ver el explorador de ramas como en la figura inferior, y puedes utilizarlo además para cambiar a esa rama y empezar a trabajar con ella.



También se puede ver la información de las propiedades de la rama y comprobar un pequeño esquema que muestra cómo está configurada la rama.



Trabajando en la primera tarea

Centrémonos ahora en el primer trabajo que tenemos que realizar: modificar el formulario para que tenga una mejor presentación, una parte para editar más ancha y fondo en verde. También modificaremos el código asociado al botón OnClick para realizar una acción diferente como muestra la figura de abajo.



Ahora utilizaré otra herramiente muy útil desde el menú de control de código fuente: la herramienta de revisión de cambios. Utilizando esta opción obtengo los siguientes resultados que muestras cómo he modificado el código del Button1Click.



Así que ahora puedo proteger mis primeros cambios: he modificado los ficheros .dfm y .pas.



Me acabo de dar cuenta de que no me gusta el cambio que acabo de hacer en el código (creo que ni siquiera está funcionando), así que vuelvo a modificar el fichero .pas y escribo el siguiente código:



Lo bueno de utilizar una rama para cada tarea es que no te tienes que preocupar de cuántos commits (o protecciones) haces: simplemente proteges cuando quieras guardar una copia, el código no irá a la línea principal del proyecto así que no afecta a nadie incluso si los cambios intermedios no compilan, y se puede seguir usando el control de versiones como mecanismo de versionado.

Finalmente cambiaré el fondo del formulario para que parezca más feo con color verde.



¿Qué ha cambiado en el fichero .dfm? Lo bueno de .dfm (al menos desde la versión 2, si recuerdo bien, cuando se convertían de formato binario a texto) es que toda la interfaz gráfica está definida en formato de texto (si, ahora estamos todos acostumbrados, pero Delphi era capaz de hacerlo...¡hace diez años!), con lo que se pueden utilizar fácilmente las herramientas de diferencias y de integraciones.



¿Que apariencia tiene mi explorador de ramas después de trabajar en la misma rama?



Colocar un gráfico en el formulario

Bien, consideramos lo siguiente: antes de que termine con la primera tarea de programación un segundo desarrollador comienza también a trabajar en la aplicación. Él ha incluido un gráfico en el formulario.

Comenzará a trabajar desde la última versión estable de nuestra aplicación de testing, que era intial_version. Su explorador de ramas tendrá la siguiente apariencia:



Por favor, ten en cuenta que he activado los enlaces de parentesco para esta captura, por esto ahora se ven las líneas amarillas que señalan desde una rama hasta su punto de partida.

El desarrollador añade un gráfico en el formulario que tiene la siguiente apariencia:



Hay que tener en cuenta que no estoy viendo el fondo verde ni el resto de cambios que ha realizado el otro desarrollador en task001 porque estoy partiendo de la última línea base estable.

Bueno, puedo oir que alguna dice: “eh, pero entonces tendrás que reorganizar todo el dfm manualmente después de hacer los cambios en paralelo”. Creedme, esto no es así.

Aquí podéis ver el árbol de versiones en 3D que muestra el fichero dfm que contiene la definición de la GUI:



Si, se puede ver claramente que el desarrollador de task001 ha realizado dos cambios en el formulario, y el de task002 tan solo ha realizado uno... ¡en paralelo!

Y para que las cosas sean un poco más complicadas también voy a modificar el evento OnClick escribiendo el siguiente código:



Integración de cambios

Es el momento de integrar los cambios en la línea principal. En este momento tu desarrollo tiene la siguiente apariencia:



Ahora tan sólo hay que ir al explorador de ramas, seleccionar botón derecho en la rama principal y en "cambiar a rama".

Entonces elegimos task001, damos al botón derecho y seleccionamos "integrar desde esta rama", entonces Plastic mostrará el diálogo de merge:



Estos son los dos ficheros que han sido modificados en la rama task001. No habrá ningún tipo de conflicto ya que es la primera rama que estamos integrando y desde entonces se ha modificado Unit2.dfm, no Unit2.pas. En la columna de los contribuidores se puede ver que dos de ellos tienen Source como contribuidor, lo cuál significa que se han realizado cambios sólo en task001 y no en la rama principal.´

Damos a la opción de "merge all" y Plastic realiza la integración.

Después de que está terminada la integración los ficheros que se han visto afectados se quedan en estado desprotegido por lo que se pueden proteger, compilar el código y verificar que todo se ha realizado correctamente.



También se puede comprobar desde el árbol de versiones del fichero Unit2.pas:



Muestra una nueva flecha verde que significa que se ha realizado un merge.

Este es el modo en el que se almacena el seguimiento de las integraciones.

He construido la aplicación y esta es la apariencia una vez que se ha integrado task001 (bueno, hasta ahora sólo task001 está en la rama principal):



Y aquí se puede ver cómo queda el explorador de ramas después de la primera integración, y los ficheros están protegidos:



Integración de task002

Integrar task001 ha sido muy sencillo: los cambios realizados en la rama se copian en la rama principal, no se realiza una verdadera integración entre las distintas revisiones.

Pero ahora con la rama task002 las cosas son diferentes ya que se han modificado los mismos ficheros que en task001.

Si se abre el diálogo de merge dando al botón derecho en la rama task002 y seleccionando "merge desde esta rama" se verá lo siguiente:



¿Qué es diferente ahora?

Hay que tener en cuenta que la columna de los contribuidores ahora dice que los ficheros se han cambiado tanto en la rama principal (después de integrar task001) como en task002.

Realizamos la integración y comprobamos como el fichero dfm se integra de manera automática, lo cual es una buena noticia.

La integración del fichero .pas necesita algo de ayuda: si te acuerdas, modificamos exactamente el mismo método dos veces de dos maneras diferentes, así que Plastic no sabe exactamente cómo resolver el conflicto.

Aquí aparece la herramienta de merge de tres vías:



¿Qué hay aquí?

El panel origen muestra el fichero que se está integrando desde task002. El panel base muestra Unit2.pas como estaba antes de que se realizaran los cambios: como estaba en initial_version. Y finalmente el panel de la derecha, el fichero de destino, muestra the Unit2.pas como está ahora en tu espacio de trabajo después de haber integrado la rama task001.

El panel inferior es el que muestra los resultados y propone agrupas los tres bloques, que es algo que se tendrá que modificar.

Por favor, ten en cuenta que la herramienta de merge de tres vías está detectando 3 conflictos, pero ha resuelto dos de ellos de manera automática ya que no estaban afectando a las mismas líneas de código.
Yo decido quedarme con los cambios de las dos tareas pero no con el de la base:



Todo integrado

¿Qué apariencia tiene mi formulario después de la integración? Bien, pues como esperabamos tiene el fondo del color de la tarea task001, el botón y la opción de editar modificados y el gráfico incluido en la tarea task002 como se puede ver debajo:



Lo mejor aquí es que ambos desarrolladores han podido centrarse en los cambios que tenían que realizar sin preocuparse el uno del otro hasta que terminaron sus modificaciones, y entonces Plastic se ha ocupado de integrarlas.

El árbol de versiones del fichero Unit2.pas ahora será:



Conclusión

En mi humilde opinión Delphi es aún uno de los entornos de desarrollo más potentes que existe, y por supuesto que se beneficia de todas las ventajas de una buena gestión de ramas y de integraciones. Plastic se puede integrar con Delphi con ayuda de SourceConneXion y parece que forman un equipo estupendo trabajando juntos.

Claro que como desarrollador que ha utilizado duranto mucho tiempo Delphi (he trabajado bastante tiempo con Kylix), es siempre un placer el poder ver cómo el equipo de Delphi gestiona la evolución de su herramienta.