Over time, we've tried to tighten up some loose bits of our enforcement of
revision log messages being stored in UTF-8. One side effect appears to be that
'svn log' will choke on the client-side if a log message is *not* UTF-8, as the
XML parser finds this most disagreeable.
But in researching this problem, I find that the mod_dav_svn's log handling code
is just generally sloppy about its on-the-wire deliverables in this respect.
Not only does the logic in mod_dav_svn's log report handling rather
optimistically assume that Subversion's revision properties are properly
encoded, but it rather naively assumes that any custom revision properties which
might exist in the repository also have UTF-8 values, despite there being no
such requirement placed on them.
Thus, you can successfully set a binary-valued revision property from the
command-line:
$ svn propset -r1 --revprop my-custom-prop -F thumbnail.jpg
but when you try to fetch that property from the server via 'svn log
--with-all-revprops', Subversion chokes.
You can, however, use 'svn propget' to fetch the property. That codepath takes
us through a different part of mod_dav_svn -- one which base64-encodes any
revision properties that aren't valid UTF-8.
mod_dav_svn does only a very naive fuzzy-escaping of XML-unsafe characters, and
only for log message properties, when responding to 'svn log' requests.
Bug
Critical