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.
Received on 2011-12-14 17:33:57 CET