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.