[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Invalid control character '0x0d' in path error using svnadmin dump and load

From: Stuart Roebuck <stuart.roebuck_at_ed.ac.uk>
Date: 2007-08-14 15:03:39 CEST

On 14 Aug 2007, at 13:15, Erik Huelsmann wrote:

> On 8/14/07, Stuart Roebuck <stuart.roebuck@ed.ac.uk> wrote:
>> I'm running across a problem dumping and re-loading an existing svn
>> repository which contains file names with '0x0d' characters.
>>
>> This problem has been experienced by others and is documented on a
>> number of blogs and wikis including...
>>
>> <http://wincent.com/knowledge-base/Repository_migration>
>>
>> Nobody appears to have found a good solution to what appears to be a
>> straight-forward bug: if the '0x0d' characters shouldn't be accepted
>> by SVN they should not be in the dump of an existing SVN repository.
>
> I do understand the problem, but leaving out the 0x0d characters is no
> option, as the dump should be an exact copy of what is in your
> repository.
>
> What would be better is if you had a tool which would help you resolve
> the situation with the dump better. The course of action taken by
> Wincent is a bit drastic, I'd say, because others have written tools
> to manipulate dumpfiles, maybe one of those supports mangling
> filenames.
>
> First and foremost, what you're seeing might be a bug in Subversion.
> How did your repository get into this state? Which version was used to
> create it, which versions were used to commit to it? Has the
> repository been served and accessed with non Subversion WebDAV
> clients? What other version information can you provide us with?

In my case I have come across this in two separate SVN repositories.
One running on a Mac running Mac OS X, one running on Fedora Linux.
Neither were set up for WebDAV serving - all accesses for their
lifetime were direct svn or svn+ssh. In both cases the repositories
were originally served with earlier versions of subversion which were
progressively upgraded over time, so the entries may have occurred as
a result of transient errors in subversion.

Unfortunately, the end result is a repository that cannot be dumped
and re-loaded without some intervention.

My current choice of intervention is to use 'sed' to remove the extra
0x0d character from the end of the filename in the dumpfile so as to
produce a repository with all the files in tact - just a single rename.

This appears to have worked.

>
>> I've looked through the reported issues on the issue tracker and
>> can't find an entry for this issue. So this is my buddy-finding
>> attempt.
>
> The more information we can get, the better we can target the issue to
> be filed. I hope you can help us.
>
> bye,
>
>
> Erik.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>

------------------------------------------------------------------------
-
Stuart Roebuck e-mail:
stuart.roebuck@ed.ac.uk
Project Manager
University of Edinburgh Tel.: 0131 651
1417

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 14 15:01:39 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.