On Fri, 2004-02-27 at 12:03, C.A.T.Magic wrote:
> apache2 was restarted during a change. the DB got corrupted.
No, it didn't get "corrupted", it got interrupted and left in an
inconsistent state. You had to recover to rollback to a consistent
state. The book talks about this, and so does the FAQ. Anytime a
process is "killed" while accessing the database, this will happen.
> Note: don't blame it on TortoiseSVN. you can't
> blame the used client for a corrupted history in the DB, can you?
Are you *sure* the repository has things in the wrong place? Have you
browsed the repository with a web browser? Or have you used 'svn ls -r
N URL' to look at older revisions?
I ask this, because it's possible that your working copy is very
confused about what URL it's representing. If it claims to be a
different URL than you expect, the server will send it information
appropriate to that URL.
In other words, there's a very good chance that the working copy is
confused (we see that from time to time), but I'm skeptical about the
repository history being wrong.
> 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
> probably (atomic, correctly) not recordet.
Ok, so far, so good. Apache was killed, the database had to be un-stuck
as expected, and your commit-in-progress was interrupted and not
committed.
It sounds like revision 32 is just a file-add. Would you verify that?
How about running 'svn log -v -r32 reposURL', and showing us the output,
so we can see exactly which paths changed in r32.
> 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).
Are you sure your working copy was at r31? Are you sure nobody ran 'svn
mv' on the individual files?
> 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.
This is an extreme claim to make. In three years of using the
repository database, we've never heard of or seen anything like this.
Here's what we need to see: you need to run 'svn log -v reposURL' so we
can see exactly which paths changed from r32 (HEAD) all the way down to
r1. There's no point in guessing what the commit history is in the
repository: just run 'svn log -v' to find out. You don't need to dump
into a dumpfile... that's overkill.
Once we can see the 32 logs with path information, then we can start to
figure out what's going on.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 27 21:06:27 2004