Svnserve y sus cuelgues del demonio...

Subversion es un sistema de control de versiones que en general funciona de PM...

Cuando empieza a dar problemas es, como no, en sistemas Windows ¬¬ cuando se tienen repositorios grandes servidos por svnserve.

Descripción del problema:

• Cuando se hace commit de ficheros grandes (a partir de 1 mega) el cliente se queda colgado indefinidamente al enviar este fichero grande (no parece haber actividad de red). Al pasar mucho tiempo, se muestra un error indicando que no se ha podido completar la operación.
  

Entorno donde se produce el problema:

• Repositorio está en un sistema Windows (XP SP2 para más señas). Sí, seguramente esto no pase en GNU/Linux. Si lo tengo en Windoze es por motivos laborales.
  
• El repositorio es relativamente grande: 280 megas y unos 160 commits.
• El repositorio se sirve a través de un servidor svnserve (los clientes usan por lo tanto protocolo svn://).
  
• Las versiones de subversion son la última disponible (la 1.4.4), tanto en el cliente como en el servidor. Se ha observado este problema en otras versiones anteriores de la rama 1.4.x
• Has 2 clientes: uno local (desde la misma máquina del repositorio) y otro remoto (otro PC también con windows). El problema sucede en los dos (todos acceden al repositorio con el protocolo svn://).
  
• El problema sucede indistintamente al usar clientes de consola (svn) o gráficos (TortoiseSVN).
  

Intento de solución 1 [fallido]: Usar Apache + módulos de Subversion en lugar de svnserve.

• Esta solución, a parte de ser tediosa (requiere instalar Apache 2, los módulos de subversion, configurarlo todo y hacer un svn switch --relocate en los clientes) NO funciona: se sigue colgando los clientes en hacer commits de ficheros grandes. En este caso, los clientes usan el protocolo subversion http://.
  

Solución -cutre- al problema [funciona!]:

• Parece ser que este problema sólo sucede cuando se accede al repositorio por red. Seguramente sea un fallo en alguna librería que usa el Subversion (como la Apache APR), o algun fallo en el propio Subversion, vete a saber...

• IDEA brillante: ¡no usar la red entre cliente y el repositorio! :D

• En el cliente que está en la misma máquina que el repositorio esto es fácil: sólo hay que hacer un svn switch --relocate en la copia local apuntando como dirección del repositorio una que empiece por file:///C:/ruta/al/repositorio, donde C:/ruta/al/repositorio se corresponde a la ruta real donde se encuentra el repositorio en esa misma máquina y file:/// es el protocolo subversion para acceso local.

• En el cliente que está en una máquina diferente a la del repositorio parece ser imposible acceder al repositorio de "forma local" estando estos dos en máquinas diferentes. Pero estando en un sistema Windows, aquí es donde aplicamos la "ingeniería creativa": usamos la compartición de red de Windows que parece soportar Subversion por defecto. En el servidor hacemos que la carpeta del repositorio esté compartida por red. En el cliente tenemos 2 opciones:

• Usar mapeo de unidades (no lo recomiendo ya que habría que hacerlo a cada sesión): en el cliente remoto hacemos el svn switch --relocate con una ruta local, donde la unidad Z corresponde a la unidad remota montada localmente con "Conectar a unidad de red" de "Mi PC", p.ej.: file:///Z:/nombreCarpetaRepositorioCompartida

• Usar rutas UNC: en el cliente debemos hacer el svn switch --relocate con una ruta del estilo file://nombreDeRedPCServidor/nombreCarpetaRepositorioCompartida. ¡Ojo que aquí el file:// sólo tiene 2 barras! Obviamente el nombreDeRedPCServidor corresponde al nombre de red del PC donde está el repositorio y
  nombreCarpetaRepositorioCompartida es el nombre que le hemos dado a la carpeta del repositorio al compartirla.

Esta solución cutre tiene sus ventajas:

• No es necesario tener ningún servidor corriendo en la máquina con el repositorio (ni svnserve ni Apache), puesto que quien "escribe" y modifica los ficheros del repositorio realmente es el cliente, ya sea local o remoto.
  
• Es una solución más "rápida" que las otras de red: no hay un protocolo svn:// o http:// por medio.
  

Evidentemente, también tiene desventajas:

• Sólo sirve para redes locales (supongo que para el caso de redes no locales se podría hacer otro cutre-apaño con túneles VPN).
• Es una solución cutre. Lo suyo sería que se solucionase el problema en el propio Subversion.
  

Instalar DBDesigner 4 en Ubuntu Linux (Feisty Fawn y Gutsy Gibbon)

DBDesigner 4 es un sistema de diseño visual de bases de datos que integra diseño, modelado, creación y mantenimiento de estas en un único entorno. Está pensado para crear bases de datos MySQL pero permite algunos sistemas comerciales como Oracle o SQLServer y -con ciertos trapicheos- es posible crear esquemas para otros SGBD libres como PostgreSQL.

Es un sistema de código libre (GNU GPL) y se pueden obtener sus ejecutables desde la web http://fabforce.net/dbdesigner4/, desde la que se ofrecen versiones para GNU/Linux y Windows.

Otra cosa es que estos binarios funcionen tal cual en GNU/Linux y... ¡Sorpresa! En Ubuntu no rulan por defecto. La única forma en que están estos empaquetados para Linux es en un fichero .tar.gz

Tras indagar un poco, estos son los pasos para hacer que el programa vaya como la seda:

1. Descomprimir el .tar.gz con el programa en un directorio (se recomienda el directorio HOME para un sólo usuario y el directorio /usr/local/bin para una instalación de sistema).
• $ cd ~
• $ tar xvzf ruta/a/la/descarga/DBDesigner4.0.5.4.tar.gz
• $ cd DBDesigner4
2. Instalar paquetes con las librerías necesarias. En una consola, ponemos:
• $ sudo aptitude install libxft1 libstdc++2.10-glibc2.2
3. Con los dedos cruzados, probamos si funciona:
• ./startdbd
4. [Paso estético: cambiar fuentes del programa]
• En el menú "Options -> DBDesigner Options" escogemos la pestaña "Visual Options" y cambiamos la fuente a, por ejemplo, Bitstream Vera Sans con 8 puntos en el desplegable "Application font".
• En el menú "Options -> Model Options" escogemos la pestaña "General Options" y en el desplegable "Default Font" cambiamos la fuente a Bitstream Vera Sans.

En caso que no arranque el programa, podemos mirar el fichero de log que se creará en ~/.DBDesigner4/DBD4.log para ver qué problema hay.


ACTUALIZACIÓN: Instalación en Gutsy Gibbon

Es necesario bajar e instalar la libreria liborqt (adaptado de aqui):

$ wget ftp://fr2.rpmfind.net/linux/sourceforge/s/sk/skychart/libborqt-6.9.0-2.i386.rpm
$ sudo apt-get install alien
$ sudo alien libborqt-6.9.0-2.i386.rpm
$ sudo dpkg -i libborqt_6.9.0-3_i386.deb

Luego le indicamos al programa dónde encontrar la nueva libreria:

$ cd ruta/donde/hemos/descomprimido/DBDesigner4
$ cd Linuxlib
$ mv libqt.so.2 libqt.so.2.old
$ ln -s /usr/lib/libborqt-6.9-qt2.3.so ./libqt.so.2

En Gutsy ya no existe el paquete libxft1. En su lugar, se debe instalar el libxft2:

$ sudo apt-get install libxft2

Y crear un enlace simbólico que permite "camuflar" la libxft2 como si fuera la libxft1:

$ sudo ln -s /usr/lib/libXft.so.2.1.2 /usr/lib/libXft.so.1

Si con el paso anterior sigue sin arrancar el programa, intentamos esto:

$ cd ruta/donde/hemos/descomprimido/DBDesigner4
$ ln -s /usr/lib/libXft.so.2.1.2 Linuxlib/libXft.so.1