Affichage des articles dont le libellé est subversion. Afficher tous les articles
Affichage des articles dont le libellé est subversion. Afficher tous les articles

mardi 3 mai 2016

Subversion fails due to power outage

Hi there,

Here I am again, fighting with subversion.

So, I had a power outage today while updating subversion and that broke the central point of failure in subversion, the wc.db.

I got the following error:

$ svn cleanup
$ svn up
$ svn: E200030: sqlite[S11]: database disk image is malformed


I have Gb's of data checked out and have a home office ... no fun checking that out again, so I simply got sqlite from the repositories, created a new db with subversion, truncated all tables, and populated with the data I recovered from the corrupt db.

If you are a poor man (Windows users), you download a version of sqlite from http://sqlite.org. A subversion sqlite database has the following type:

"SQLite 3.x database, user version 31"

You can see this if you issue "file" against it:

file .svn/wc.db

You will need Linux, Unix (incl. Mac OS X), Windows+Cygwin, or Windows 10 with Ubuntu subsystem for that "file" command to work.

Furthermore, a subversion sqlite database has the following tables:

"ACTUAL_NODE", "NODES", "PRISTINE", "REPOSITORY", "sqlite_sequence", "sqlite_stat1", "WCROOT"

As you can see, only a few. Since the db is corrupt AND I can still access the data, I will need a new db; I checked I could access the data with the following:
 
$ sqlite3 .svn/wc.db
sqlite> select * from NODES

Note that sqlite3 can create a blank db for us, however, it will not be the version subversion wants :-(, unless you take a really old sqlite3.

So, I move the wc.db out of the way and checkout a folder into a temporary directory, move the newly subversion-blessed db into position:

$ mv .svn/wc.db .svn/wc_bad.db
$ cd /tmp
/tmp $ svn co -N http://myServer/myfolder
/tmp $cp .svn/wc.db /path/to/subversion/checkout/


Now I need to populate the db ... I open the old sqlite db, dump its contents, open the new db, truncate all tables, and finally, populate all tables with data from old db:

$ sqlite3  .svn/wc_bad.db
sqlite> .mode insert
sqlite> .output dump_all.sql
sqlite> .dump
sqlite> .exit
$ sqlite3  .svn/wc.db
sqlite> delete from "ACTUAL_NODE"
sqlite> delete from "NODES"
sqlite> delete from "PRISTINE"
sqlite> delete from "REPOSITORY"
sqlite> delete from "WCROOT"
sqlite> delete from "sqlite_sequence"
sqlite> delete from "sqlite_stat1"
sqlite> vacuum
sqlite> .read dump_all.sql
sqlite> .exit
$ svn up
A some/amazing/newly/added/awesome/file.txt 
...


Hope this helps you.

Note that I got the dump commands from http://techblog.dorogin.com/2011/05/sqliteexception-database-disk-image-is.html, great entry, although in my case, the sqlite3 created db was not accepted by subversion, I got the following error:

svn: E235000: In file '..\..\..\subversion\libsvn_wc\wc_db_wcroot.c' line 269: assertion failed (format >= 1)


vendredi 31 mai 2013

Subversion fails more often

I started using subversion 1.4 back in the day, I got issues here and there, but I could easily just move the files out of the way and svn update the directory, copy the files over again ...

Ever since I upgraded to 1.5 or was it 1.6, I started getting tree conflicts, here and there, not frequent, I agree, but shit, guyz, keep it simple, I do not care about 1 or 2 ms performance increases on a commit, seriously ...

With 1.8, they did away with .svn folders in each checked out folder -it is now all centrally controlled at the root of the checked out folder ... except that now, when something fucks up, you can check the whole 10Gb out again ...


I expect products to improve over time, not seriously fuck up.

The guy who thought putting everything in one sqlite database at the root of the checkout is an IDIOT, no ifs, buts or maybes - (s)he should be Hung, Drawn and Quartered. Like, hey, we have this system where we have no single point of failure, that is bad, lets create one.