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
Received on 2011-12-15 08:41:01 CET