cmpilato@collab.net wrote:
>db_recover without the -e will destroy the __db.* files. You should
>probably just just 'svnadmin recover /path/to/repos', or if your
>Subversion rig predates the 'svnadmin recover' command, run
>'db_recover -veh /path/to/repos/db'.
>
>
Looks like it was my fault then. I wasn't avare of the '-e' option...
It has happened to me sometime around 3:00am and what I probably
did was a db4.0_recover (debian) first and then noticed the ___db*
files are gone. Sorry for confusion...
I don't know why, but I am unable to use svnadmin recover most
of the time. I says it is waiting for the exclusive lock and if not manually
killed, it would wait forever it seems. But there is no one sitting at
that lock
according to lsof (hope that locks/db.lock is the proper file) and running
the recovery by hand succeeds.
Another strange thing is that I am getting OOM quite often on update
process... last time I tried updating a directory of 1136 files (total
of ~5.6MB
of sources), according to 'top' it ate 302MB of memory. (the update was
getting a whole new directory with that number of files)... on a machine
with 256MB of physical memory and 128MB swap, I am simply unable
to update my source tree :-) I had to shot down KDE & X to get somewhere
and even then it was close :-)
Best,
Petr
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 28 00:23:40 2002