You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stuart Roebuck <st...@ed.ac.uk> on 2007/08/14 10:48:11 UTC
Invalid control character '0x0d' in path error using svnadmin dump and load
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'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.
Stuart Roebuck.
------------------------------------------------------------------------
-
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
Re: Invalid control character '0x0d' in path error using svnadmin dump and load
Posted by Karl Fogel <kf...@red-bean.com>.
Stuart Roebuck <st...@ed.ac.uk> writes:
> 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.
This suggests to me that a new FAQ entry might be more appropriate
than an issue. There's (no longer) a bug in Subversion, there's just
a need to work around legacy circumstances, using svndumpfilter or sed
or whatever.
Would you like to write that FAQ entry?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Invalid control character '0x0d' in path error using svnadmin dump and load
Posted by Stuart Roebuck <st...@ed.ac.uk>.
On 14 Aug 2007, at 13:15, Erik Huelsmann wrote:
> On 8/14/07, Stuart Roebuck <st...@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
Re: Invalid control character '0x0d' in path error using svnadmin dump and load
Posted by Erik Huelsmann <eh...@gmail.com>.
On 8/14/07, Stuart Roebuck <st...@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?
> 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