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.
