Michael Sinz wrote:
> I just ran into this problem and have not looked further than there is a
> problem.
[...]
> In a fresh/cleanly built Subversion 1.4.3 setup, I used svnadmin dump to
> generate the dump file and then just load that into a new repository as
> such:
>
> $ svnadmin dump repositories/example >example.dump
> $ svnadmin load repositories/new-ex <example.dump
>
> The dump part claimed to be successful, doing all 36 revisions.
>
> The load failed on revision #9 - where some of the special case file names
> were added to the repository.
>
> Output (trimmed) is:
>
> * adding path : trunk/tests/TestCase-~-/test.txt ... done.
> svnadmin: Invalid control character '0x7f' in path 'trunk/tests/TestCase--'
> * adding path : trunk/tests/TestCase-- ...
>
> You can see this at:
> http://svn.sinz.com/svn/example/trunk/tests/TestCase-%7F-/
[...]
So, looking at the load code, it uses the svn_ctype table to determine that the
0x7F character is a control character and does not allow it as part of the node
name during the svnadmin load process.
The question now shifts to what the correct behavior should be. Given that the
repository does contain a file with this character in it, how would one correct
the situation?
Clearly, a dump/load does not work very well. At least not as long as the 0x7F
character is marked as a control character (not that I am saying that it should
not be - it clearly is special) yet the system allowed me to create this.
It is also clear that the node names are output directly from the node.
The question should now turn to why the file was allowed to be created in the
first place. I did nothing other than to create the file and then "svn add" it
to the repository. As such, given that the file name was correctly added and
that the file correctly extracts during an "svn co" or "svn up" then the
question remains "why does svnadmin load not accept it?"
Getting rid of the SVN_CTYPE_CNTRL from 0x7F is a "quick hack" that allows
the reload of the repository. However, I am unsure that this is a safe thing
to do:
--- subversion-1.4.3-release/subversion/libsvn_subr/ctype.c Thu Dec 2
01:53:20 2004
+++ subversion-1.4.3/subversion/libsvn_subr/ctype.c Mon Feb 5 22:44:23 2007
@@ -150,9 +150,9 @@
/* { */ SVN_CTYPE_ASCII | SVN_CTYPE_PUNCT,
/* | */ SVN_CTYPE_ASCII | SVN_CTYPE_PUNCT,
/* } */ SVN_CTYPE_ASCII | SVN_CTYPE_PUNCT,
/* ~ */ SVN_CTYPE_ASCII | SVN_CTYPE_PUNCT,
- /* del */ SVN_CTYPE_ASCII | SVN_CTYPE_CNTRL,
+ /* del */ SVN_CTYPE_ASCII,
/* x80 */ SVN_CTYPE_UTF8CONT,
/* x81 */ SVN_CTYPE_UTF8CONT,
/* x82 */ SVN_CTYPE_UTF8CONT,
/* x83 */ SVN_CTYPE_UTF8CONT,
Note, also, that the output from "svn log" also will end up using the raw "0x7F"
(aka 'del') character in what it generates. This may also be invalid for XML.
Now, I don't really know how this file made it into the system as it seems like
the "svn and" command has a flaw in it as it seems to allow the creation and
storage for the very same file that "svnadmin load" fails to support.
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 6 05:03:18 2007