SVN and its new sqlite format again

I been a user of svn for a quite long time now, and had to work around certain «features», like berkeley.db locking on multiuser home directories, the migration to FS logs, and problems working with multi platform environments, most of it its documented on this blog.

Yeah, git is sexy, and fast… on linux, on windows had some issues, not that terribly bad, so why no migrate to git? Well I tested after DC12 as Jose migrated our sourceforge repository to gitorius, and also as having helped first hand with the migration of one big source on DC11, I tested beginning this year… what stopped me? well the Tortoise client for git is still lacking some features that svn had, but this was not the blocker, I wanted to had my origin on an Internet available machine, so the place for testing was DH as they host my personal blog and hobbies sites, and that was the blocker, CPU over usage on checkout… process watch killed my big clones and even small commits, yes I have voted for DH to implement better use of git and|or make it easier but with no avail, and since 2009-09-22 svn I have worked fine with DH as central repository on the net (since 2004, for this particular one.)

I’m planning on give a try again ending the semester, and had some Ideas to try that last time don’t even considered… but I would not even have think on this if not for svn migrating from their old .svn per directory to a monolithic .svn on master directory and changing to SQLITE format, in the past if you make a mistake like using one encoding or character not compatible with another OS, simply you can rename|delete .svn local directory and fix on other OS, return to the offended OS and do svn update to fix missing files with the broken names…

Last weekend I forgot to change a pipe “|” on a name that committed at work (Debian) and at home (Win7) it break my windows repo, so I tried the know old solution just to find that I can’t delete|rename per directory .svn anymore, to be fair I have this same problem last year but this time where more complex… as I attempted svn cleanup and got stuck on update | cleanup one needing the other, and if I have checked my old entry about svn and sqlite here on august 2012 have noted that I need sqlite, faster… and that this time was equally complex…

I tried deleting the locks from wc.db with DELETE from LOCKS; and no luck, as the affected repo still tried to add the files with the offending names, after reading some other responses to similar problems [1],[2].[3] I became aware that the WORK_QUEUE table holds what is pending and having a backup of the same file go ahead with DELETE from WORK_QUEUE; then things go faster, of course the repo needed a svn cleanup, and after what looked like long time a svn update that got me working again…

BTW if you need a ‘gratis’|FREE as in beer visual GUI for sqlite I found sqlitespy [4] that is easier in some ways than doing the command line work from last year, at least in Windows….


Esta entrada ha sido publicada en Debraye, Educación, planetalinux, sysadmin, Web y etiquetada como , , , , , , , . Guarda el enlace permanente.

Deja una respuesta

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

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.