Tag mercurial - Userlinux.net

No me quiero hacer pesado con este tema, pero hoy a uno de mis compañeros le ha petado el Eclipse y hemos tenido que configurar gedit para que molara, literalmente. No es que haya sido muy tedioso pero no recordaba ciertos pasos que me apetece documentar. Allá vamos.

Si trabajas con Mercurial y has actualizado a la rama 1.7.x es posible que, en tus comunicaciones https con Bitbucket aparezca un mensaje como el siguiente:

$ hg pull -u
warning: bitbucket.org certificate with fingerprint fi:ng:er:pr:in:tt not verified (check hostfingerprints or web.cacerts config setting)
warning: bitbucket.org certificate with fingerprint fi:ng:er:pr:in:tt not verified (check hostfingerprints or web.cacerts config setting)
pulling from https://r0sk:***@bitbucket.org/r0sk/proyecto
warning: bitbucket.org certificate with fingerprint fi:ng:er:pr:in:tt not verified (check hostfingerprints or web.cacerts config setting)
warning: bitbucket.org certificate with fingerprint fi:ng:er:pr:in:tt not verified (check hostfingerprints or web.cacerts config setting)
searching for changes
adding changesets
adding manifests
adding file changes
$

Este warning no implica el mal funcionamiento o la inseguridad puntual de dicha acción, simplemente informa de que siempre ha sido inseguro. Tenemos dos opciones, o dejar de usar https o indicar en configuración los certificados SSL a utilizar para que no vuelva a aparecer el warning. Esto último se consigue editando el fichero .hg/hgrc del proyecto en cuestión, agregando lo siguiente (en Debian/Ubuntu):

[web]
cacerts = /etc/ssl/certs/ca-certificates.crt

Una vez agregadas estas dos lineas en el fichero probamos de nuevo a ejecutar cualquier operación sobre https y vemos que ya no se muestran los avisos. (Fuente).

Si algo bueno tiene Mercurial es que permite la autentificación de usuarios a través de SSH. Es muy sencillo agregar un nuevo usuario a un desarrollo/repositorio: adduser y con meterlo dentro del grupo correspondiente al desarrollo llegaría. Pero ¿qué ocurre si no queremos que ese usuario haga otra cosa que no sean comandos hg?.

Conociendo la existencia de hg-ssh no ocurre demasiado, se trata de un script que hemos de referenciar en el authorized_keys del usuario que acabamos de crear de forma que todos los comandos entrantes pasen por este script. El script se encarga de parsear el comando que se pide en ejecución: si es de la familia de Mercurial lo ejecuta, en cualquier otro caso mostrará un error.

Ejemplo de authorized_keys:

command="~/hg-ssh /home/repo1 /home/repo2",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-dss AAAA...

He optado por copiar el archivo hg-ssh en el directorio home del usuario, pero se podría referenciar directamente el que trae de ejemplo la instalación de Mercurial.

Mi predilección por Mercurial ha quedado patente en algún que otro post, así que una vez estamos conforme con nuestro servidor de versiones llega el momento de dar un paso más. Intentaremos configurar un interfaz web para mostrar el código a todo el mundo (una especie de Trac solo para código y adaptado a Mercurial).

El proceso es tan sencillo como crear otro VirtualHost en tu Apache con unas características un poco especiales porque en vez de tirar de archivos dinámicos (.php, .asp…) vamos a tirar de un cgi en Python, así que la configuración sería algo así:

Cuando trabajamos con servidores de versiones seguro que hay muchas razones de peso de por medio, una de ellas -la que veremos- puede ser la replicación de código en diversas máquinas.

Supongamos un montón de máquinas que comparten el mismo código de repositorio, el orden de propagación de un cambio en todas esas máquinas es sencillo:

1. Programamos dicho cambio en nuestro servidor de desarrollo (devel).
2. Hacemos un commit local (en sistemas de versionado distribuido -como Mercurial- cada repositorio también es servidor).
3. Lo siguiente es un push al servidor donde almacenamos el código (repo código).
4. Ahora tocaría entrar en cada una de esas máquinas en las que queremos propagar el código y ejecutar un hg pull ; hg update.

Necesitaba instalar Mercurial en varias máquinas totalmente desactualizadas, concretamente una Fedora Core release 4 (Stentz) y una CentOS release 5 (final), pensé que iba a ser un lío de dependencias pero al final ha resultado inexplicablemente más sencillo de lo esperado:

Lo tenía pendiente desde que cambié de Subversion a Mercurial, sabía que se podía y que era algo trivial pero lo vas dejando y bueno, just happens. El caso es que cuando haces un push al servidor lo normal es hacer un update de su lado, así que el hook que lo automatiza es el correspondiente:

[server]$ cat /path/del/repo/.hg/hgrc
[hooks]
changegroup = hg update

Y fuera preocupaciones. La obligada referencia a Tao of Mac, desde donde me vino la inspiración mientras intentaba poner el Macbook a punto.

Después del owned con el que hemos puesto fin al 2009 ha llegado un nuevo servidor de desarrollo y con ello su consecuente migración (y problemas varios).

Ha llegado despiezado así que nos hemos puesto manos a la obra para restaurar el servicio cuanto antes, primero el hardware y luego -wiki en mano- los servicios correspondientes. El primer problema -que en principio no ha trascendido demasiado- ha sido la migración de los repositorios Subversion a la nueva máquina. Digo problema porque nunca había migrado un SVN, pero todavía sigue quedando gente que documenta estas operaciones para hacer la vida más sencilla a los demás.

Debería haber escrito este post hace algún tiempo pero ya se sabe como somos la gente importante que no tenemos tiempo a nada (modo ironic off). De todas formas nunca es tarde así que allá vamos, a adentrarnos en el maravilloso y fascinante mundo de Mercurial (hg para los amigos).

A estas alturas todos sabréis que Mercurial es una herramienta de sistema de control de versiones multiplataforma para desarrolladores de software implementado en Python (wikipedia dixit). Lo que igual se hace menos familiar es la facilidad con la que podemos crear un repositorio en 3 simples pasos:

Pensé que no funcionaba, que el plugin que había estaba desactualizado o algo así pero no es cierto, funciona a las mil maravillas. Con ésto no quiero decir que sea mejor o la tenga más grande que Netbeans, que no quiero flames, pero -al menos para mi- ya están en igualdad de condiciones para ser comparados.

Para instalarlo, como siempre, Help - Install New Software e introducimos los siguientes datos:

Name: Vectrace (Mercurial Eclipse plugin)
URL: http://www.vectrace.com/eclipse-update/

El único truco ha sido seleccionar la versión "de abajo" en la instalación y listo, a la hora de importar un nuevo proyecto ya puedo hacer clone del repo y a otra cosa mariposa. Ya sé que en la imagen no se aprecia apenas pero no me fustiguéis por ello. Por cierto una muy buena página de referencia es ésta, por si le sirve de ayuda a alguien.