Am 14.12.2011 17:33, schrieb Daniel Shahaf:
Thomas Gier wrote on Wed, Dec 14, 2011 at 17:10:26 +0100:
Hello,
this is my first post to the list so first of all I'd like to say
hello to everybody :).
I'm stuck with a problem for which even google doesn't seem to find
a solution, so I decided to post to this list. We're using SVN
1.5.1 (r32289) and access our repository with linux, mac (SmartSVN,
IntelliJ plugin) and windows clients (Eclipse plugin, TortoiseSVN)
What version of svn runs on the client side? If it's 1.5, upgrade;
there have been robustness fixes in the last 3.5 years.
Problem:
Loading a dump into a repository fails with "Invalid character "/"
in revision list".
After many hours of trying and searching for fixes I decided to take
a closer look to the binary files under<repo home>/db/revs. Since I
know the affected revision (12943), I inspected the file<repo
home>/db/revs/12/12943. This file contains a line similar to this:
/path/to/some/file:1234,1235,1237/path/to/some/other/file
For the record, you could have run 'propget --strict' or 'diff' against
the revision in question.
Other lines never have a path except at the beginning but never
inside the revision list and they always end with a line feed (0A
in binary). This particular line however doesn't. Editing the file
with an hex editor and putting an 0A at the correct position (while
preserving as much of the revision numbers as possible) seems to do
the trick.
DO NOT EDIT REVISION FILES; you just corrupted it.
The correct thing to do is a dump/load and change the property value
during that process. Doing it by hand to a dumpfile is easier to get
right (but you will still have lengths and checksums to adjust), or you
could use some third-party dumpfile manipulation tool (some tools are
standard recommendations on this list; I don't recall which offhand).
I know that by fiddling with these entries the mergeinfo will get
useless for this particular file/revision. I really don't like the
No, the mergeinfo will be fine; it's the rest of the changes in that
revision that will be corrupt. And if a file text change becomes
invalid, later revisions of that file may or may not be affected.
idea of messing around like this but I need to make sure that the
dumps remain usable. My backup strategy is dependent on usable dumps
which are created every night and moved off-site. If I can't recover
from a breakdown using the latest dump, I'm in serious trouble.
So here are my questions:
- Does anybody else have had this or a similar problem, too? What
did he/she do to fix it?
- How can this happen? Does anybody have hints/tips for further
investigation of the cause of this mess?
- Is there a way to correct this issue without using a binary editor
on the db files?
Thanks a lot for reading. Any comment is much appreciated.
Cheers
Thomas Gier
Aachen, Germany
Looks like someone committed a bad svn:mergeinfo property. Newer
servers check for this and newer clients handle that gracefully (so you
may not _have_ to fix your history). Just don't get in the habit of
editing revision files if you care about your data.
Daniel,
thanks for your comments! My gut feeling told me, that it's a bad idea
to edit the revision files. That's why I asked on the list. For the
record: The live server is still untouched. I edited the revision files
in a copy of our svn server (it runs as a virtual machin.
What version of svn runs on the client side? If it's 1.5, upgrade;
there have been robustness fixes in the last 3.5 years.
We have several different clients due to our heterogeneous
infrastructure. All of them should be set up to use 1.5. An upgrade is
definitely a good idea, discussions about doing this have just started.
I found 3 corrupted revisions so far starting at rev. 12943, HEAD was at
14667 yesterday evening. I haven't checked in depth yet, whether all of
the corrupted revisions are caused by the same client; my main focus is
to get the backups up and running again. Punishing the culprit will be
my next focus ;).
I going to search the list archives for the tools you mentioned to
manipulate dump files. Thanks again for helping me. If there are other
tips worth sharing these would be much appreciated.
Cheers
Thomas Gier
Aachen, Germany
