subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <>
Subject Re: Invalid character "/" in revision list
Date Wed, 14 Dec 2011 16:33:06 GMT
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.

View raw message