the short story:
apache 2 was restarted during a change,
and after db recovering the working dir
a whole folder content appearad in the wrong folder.
even the whole folder history was incorrectly
"linked" there.
the long story:
client: WindowsXP, TortoiseSVN-1.0.0
server: Suse Linux, SVN-1.0.0, Apache2/WebDAV
I think I was just deleting a _file_, using TortoiseSVN's
Repo Browser function, when our Administrator
restarted the Apache2 on the SVN-TestServer.
TortoiseSVN stopped responding for a long time so i
aborted it.
When the server was up again i got "500 server errors"
when trying to access the repository. The reason behind
this strange errormessage from TortSVN was a "DB error".
In the Apache2 log I found these messages:
>>
[Fri Feb 27 12:07:39 2004] [warn] child process 22569 still did not exit, sending a SIGTERM
... (reboot of the server, various boot messages )
[Fri Feb 27 12:07:44 2004] [error] [client 192.168.81.224] (20014)Error string not specified yet: Berkeley DB error while opening environment for filesystem /data/svn/db: DB_RUNRECOVERY: Fatal error, run database recovery
<<
I ensured that no other reason like wrong permissions or configs caused this error
and nobody accessed the svn, then ran the svn recovery:
>>
svn@CVS:/data/svn> svnadmin recover /data/svn
Recovery completed.
The latest repos revision is 32.
<<
from the svn logs i found out that revision 32 was a file commit about an hour
before the Apache reboot happened. so my file delete was (atomic, correctly)
not recordet.
BUT then happened something weird:
When i next ran a TortoiseSVN "update" on my working dir (at rev 31 before)
the update process removed a complete folder and its content ("del")...
just to let all the folder contents (consisting of files AND other folders)
reappear ("add") two folders (think of "../..") below the position where
it originally was, with the folder contents added to the previous content
of that folder. The folder content was not "moved" there like on a usual
folder move operation but was completely downloaded from the server again
(as if it was a new import).
It seems to me that all the files got incorrectly "hardlinked" to the wrong
directory ID.
checking out previous revisions (30,29,28,27) did not change anything,
the files stayed in the wrong folder. (I guess even tagged/branched versions
would appear in that incorrect folder, but unfortunately the folder had
no tag/branch to verify that).
The log files indicate that all files still are at "rev.27 - Initial Import",
nobody ever touched them since their first import. They just got "DB corrupted"
to the wrong directory.
maybe a "svnadmin dump" would give a cloue to what happened, but unfortunately
the dump has a size of about 1.5 GigBytes! does the dumpfile contain whole copys
of every revision instead of incremental patches??? It seems the dump will grow
beyond good for large repositories with _many_ _tiny_ changes on _large_ files!
I hope somebody can reproduce what happened and fix it.
before an important repository vanishes into the DB void...
======
c.a.t.
>> ------- Additional comments from sussman@tigris.org Fri Feb 27 07:42:39 -0800 2004 -------
>> The issuetracker is not a tech support forum. There's no clear bug here, and we
>> only file bugs after developers a certain that you've discovered one. Your
>> whole description sounds like you simply need some tech support or de-confusing.
>> This is why we have the users@ list, and why our big yellow box on the front of
>> the issuetracker explicitly asks people not to post issues without talking to
>> the mailing lists first. :-)
>> So I'm closing as INVALID. Please post all your information to users@, and
>> folks will help you out.
>thanks for the fast response, i'll go and post it there, BUT
>please don't underestimate this bug so easily.
>i assure you this IS a "clear bug" as you call it.
>
>or how else could files move "in history" and across
>a few folders just by running svnadmin recover???
>
>svn has a LONG way to go and it will certainly NOT go it
>by moving serious errors to INVALID without thinking a minute.
>
>====
>c.a.t.
Received on Fri Feb 27 19:04:11 2004