De svn y su nuevo formato sqlite

O como le había puesto primero, para recordar… que ahora sería para olvidar y ojala no me tope de nuevo con este error.

Bueno en la versión 1.7.x de Subversion, tuve un error realmente estúpido, bueno yo me la busque, pero pensé que sería realmente fácil corregirlo, en Linux, en mi oficina hice commit de una revisión que incluía en los nombres de archivo algo así como ¿Qué son los layers o capas? Es decir incluía ¿? Hay que poner en contexto que la API de sistema de archivos de Windows no soporta o usa como caracteres reservados “:<>\/.*?” uno de estos archivos trono mi repositorio en Windows, intente, primero borrar el directorio, hacer cleanup y nada.

Buscando en stackoverflow [1] encontré un poco como modificar las tablas que ahora usa svn, antes cada directorio contaba con un subdirectorio .svn y borrando ese y haciendo modificaciones se podían arreglar muchas cosas, el día de hoy svn pone todo en un solo directorio .svn en el raíz de la copia que estemos usando del repositorio y si algo falla hay que modificarlo vía sqlite3 al archivo de control wc.db

Esto fue lo que hice primero:

D:\Ya ordename!\UPN1\.svn>sqlite3 wc.db
SQLite version 3.7.13 2012-06-11 02:05:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> select * from WORK_QUEUE;
12280|(file-install 114 Area4/2012-1/especializaci├│n/Tercer Bimestre/Materiales
 2/Guias y ayudas/81 - ┬┐Qu├® son las capas o layers?.html 1 0 1 1)
sqlite> delete from WORK_QUEUE where id = 12280
   ...> ;
sqlite>
^C
D:\Ya ordename!\UPN1\.svn>sqlite3 wc.db

Claro antes de eso en mi linux corregí la revisión donde tronaba, cambie los nombres por unos que no le hicieran ruido a windows, e intente hacer un update, pero me pidió primero hacer un clean up, medio funciono pero de nuevo regreso el mismo problema.

Leyendo más sobre sqlite busque, que más tablas pudiera haber, claro también me di un clavado a la documentación de svn que por cierto esta en svn [2] y el libro rojo [3] y la lista de discusión de users [4] medio me dio una idea de por dónde podría ir la cosa

sqlite> .tables
ACTUAL_NODE    NODES          PRISTINE       WC_LOCK
EXTERNALS      NODES_BASE     REPOSITORY     WORK_QUEUE
LOCK           NODES_CURRENT  WCROOT

Resulta que en NODES está la revisión que rompe con todo, después de un buen rato de quebrarme la cabeza, logre dar con el nodo como no encontré un mejor identificador probé con checksum así al final para deshacerme del que me estaba dando problema, primero lo ubique es decir primero me tuve que soplar un SELECT * from NODES; así encontré el que estaba causando problemas, como lo único que encontré para poderlo elegir fue el checksum hice DELETE FROM NODES where cheksum = ‘$sha1$13d8565db1b395f5ab04f5207f3bdb72c43b4013’; hice cleanup y ahora si logré hacer update y recuperar mi copia de trabajo.

Baste de decir que me tomo un poco más de una semana resolverlo, mientras tanto hice un checkout en otra parte del sistema de archivos que tomo unas 4 horas debido a la velocidad de conexión, así que una solución rápida hubiera sido tan solo trabajar con un nuevo checkout, pero me dejaba con muy mal sabor de boca y peor, sin saber por que las cosas no funcionaban.

Una advertencia meterse a jugar con wc.db puede dejar su copia realmente mal muy rápidamente tengan bastante cuidado al mover directamente allí.

[1] http://stackoverflow.com/questions/158664/what-to-do-when-svn-cleanup-fails
[2] http://svn.apache.org/viewvc/subversion/trunk/notes/wc-ng/
[3] http://svnbook.red-bean.com/
[4] http://mail-archives.apache.org/mod_mbox/subversion-users/201203.mbox/%3CCAB84uBVFokWL5mDtRCQmnBvNGg6rK+dnC7TD+-VjxHQ9y6c5bA@mail.gmail.com%3E

Esta entrada fue publicada en General, planetalinux, sysadmin, Trabajo. Guarda el enlace permanente.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *