Notas publicadas en la categoría Postgresql

En general, los ambientes integrados de desarrollo (también conocidos como IDE) son similares en su concepción: están orientados al desarrollo de nuevos programas o aplicaciones. Y en las charlas de programación que he dado, siempre es una pregunta frecuente entre los interesados en un nuevo lenguaje o ambiente.

Por otro lado, todo libro de Ingeniería de software indica que el mayor esfuerzo se encuentra en la mantención del código; ya sea vía añadir una nueva funcionalidad o bien corregir algún un fallo. Pero los IDE no tienen una orientación hacia la mantención. Hay un estudio hecho en la Universidad de Carnegie Mellon, publicado en diciembre de 2006 en IEEE Transactions on Software Engineering, titulado «An Exploratory Study of How Developers Seek, Relate, and Collect Relevant Information during Software Maintenance Tasks» (disponible en la página del autor), que sirve para darse una idea del comportamiento de los programadores cuando deben mantener código ajeno.

Tal vez podría entenderse como un estudio de usabilidad de un IDE, en este caso: Eclipse. Se muestran los puntos débiles así como sugerencias para mejorar el entorno de cara a la mantención.

De forma particular, el artículo me llamó la atención porque precisamente mi incursión en el código de Postgresql para mi proyecto en Google. No es que el artículo me fuera ayudar mucho en términos prácticos, pero si para satisface mi curiosidad acerca de lo que se teje últimamente al respecto.

Uno de los aspectos relevantes es la falta de un buen apoyo en la navegación del código. Allí no mencionaron que existen otras herramientas para dicho proceso, que muchas veces pasan desapercibidas. Es el caso de CScope, que existe hace mucho tiempo en UNIX y que es libre desde el año 2000.

CScope es una herramienta para buscar y navegar a través del código. Para que la búsqueda sea rápida, CScope genera una base de datos de todos los símbolos de un proyecto. Y es realmente rápido. En los IDE existen algunos mecanismos de búsqueda, pero no tan cómodos y potentes.

Interfaz curses de CScope

Es muy útil, no sólo cuando se carece familiaridad con el código. Lo que desconocía es que nuestros vecinos de KDE disponen de una interfaz gráfica llamada KScope. Es fácil tener a la vista desde que archivos se hace referencia a un símbolo (sea función, variable, etc.) e incluso una gráfica personalizable. En cada caja es posible ver donde se define, que funciones llama, desde donde es utilizada, entre otras búsquedas.

Lo mejor de todo, es que uno puede utilizar indistintamente cualquiera de éstas dos interfaces. La gracia de KScope es la persistencia de la sesión, así, la siguiente vez se inicia en el mismo punto que uno quedó en la última sesión.

Ya tengo funcionando un repositorio alternativo de Postgresql para ser usado con Mercurial, el cual se actualiza cada hora.

El estado del repositorio es «funciona para mis necesidades», mejor de lo que había pensado originalmente.

El repositorio contiene todo el historial de Postgresql, aunque no contiene ninguna de las ramas. Actualmente ocupa 191 MB; mientras que el repositorio CVS ocupa 331 MB.

Me gustaría añadirle las ramas para ver el uso de espacio en disco entre ambos repositorios. Además, que podría ser de utilidad para otros desarrolladores en algún momento.

Para crear mantener sincronizado el repositorio he utilizado una mezcla de rsync con cvs20hg. Al ejecutarlo por primera vez tardó alrededor de 4 horas; y el tiempo de las posteriores actualizaciones se mide en segundos (incluyendo el rsync). Basta ejecutar los siguientes comandos:

    $ rsync -azCH --delete rsync.postgresql.org::pgsql-cvs ${MIRROR_DST}
    $ LC_ALL="en_US.ISO-8859-1" cvs20hg ${MIRROR_DST} pgsql ${HG_DST}

MIRROR_DST corresponde al directorio de destino de la copia del repositorio CVS de Postgresql; y HG_DST es donde se aloja el repositorio para Mercurial.

Para comenzar, seguiré la siguiente línea de trabajo:

Si el guía trabaja de una forma, intenta trabajar como tu guía hasta que te sientas suficientemente cómodo para seguir tu propio camino.

Lo primero es definir la estructura de directorios de acuerdo al flujo de trabajo. En este caso, seguiré la forma en que Alvaro lo hace.

    pgsql/
             source
             install
             build

Dentro de source, un directorio por cada versión de trabajo. Alvaro maneja múltiples versiones porque es su trabajo. Yo sólo necesito 2: la rama principal de desarrollo (CVS HEAD) y el árbol para mi proyecto: autovacumm. Similar caso sucede para los directorios install y build, para la instalación y contrucción de los programas, respectivamente.

Tengo algunas alternativas para trabajar. Mantener vía cvs la rama principal, y en dicha copia manejarla con Mercurial. Así, por cada actualización (cvs update), aplicaré los cambios en el repositorio con Mercurial (hg commit).

El repositorio de trabajo, entonces, es una rama de mi repositorio principal, la cual la puedo crear con hg clone. Cada cierto tiempo, puedo sincronizar ambos repositorios y si se presentan conflictos, resolverlos tan pronto como sea posible; en vez de esperar hasta el final, donde puede ser más difícil conciliar los cambios. Esto vía hg pull desde el repositorio de trabajo y hg merge.

Como alternativa de trabajo, puedo manejar una cola de parches, con la extensión mq. Esto es, antes de sincronizar ambos repositorios, extraer los cambios en el repositorio de trabajo (vía hg qpop -a), sincronizar y posteriormente volver a aplicar los cambios (vía hg qpush -a).

Con cualquiera de las dos alternativas, y en caso de conflicto, puedo mezclar visualmente los cambios con meld, que es ejecutado automáticamente cuando surge un conflicto.

Lo siguiente es obtener el código fuente. Las instrucciones para obtener el código vía cvs es distinta a las que usualmente he empleado en otros proyectos. Ellos exportan el árbol con toda la historia de cvs vía rsync. Sólo necesito una imagen de lo que hay en el repositorio en un momento determinado. Mi tiempo cero de desarrollo es cuando obtengo el repositorio por primera vez, y puedo abstraerme del historial antiguo.

Siguiendo la estructura de directorios y el flujo de trabajo de Alvaro (aunque con ligeras modificaciones para manejarlos con Mercurial), puedo usar los mismos scripts que él, de los cuales comentaré mas adelante.