Thanks for the feedback. What I've done for the moment is this:
I've made a hacked-up variant of svnsync which will correct impure
eol-style in property values where the real 1.6.0 complains and dies.
(see patch at end of mail).
This is obviously not a permanent solution.
Our central Subversion server will be seeing an upgrade from 1.4.x to
1.6.x sometime before summer (one hopes). At this point I'd like to
have our repositories dumped and reloaded anyway to be able to make
best use of the improvements in 1.5.x and 1.6.x. This would be a
natural time to filter through the whole dump file correcting the (no
doubt numerous) eol-style impurities. (A lot of us here use
RAD+Subclipse on Windows).
I don't intend to write a hook script to prevent this kind of
corruption. Even if I catch new errors of this kind, I'll still need
to clean up the dump repository when we transition to 1.6.x because of
the errors that have already crept in. As I understand it the
Subversion server 1.6.x will refuse these kinds of commits, even
without a hook script, yes?
Don't try this at home kids: this is an *evil* hack. A validation
function which mutates an input marked as const is truly not a pretty
@@ -182,15 +182,15 @@ validate_prop(const char *name, const
svn_string_t *value, apr_pool_t *pool)
- /* Disallow inconsistent line ending style, by simply looking for
- * carriage return characters ('\r'). */
- if (strchr(value->data, '\r') != NULL)
- return svn_error_createf
- (SVN_ERR_BAD_PROPERTY_VALUE, NULL,
- _("Cannot accept non-LF line endings in '%s' property"),
+ /* Evil hack: replace '\r' in property value with space to
+ * maintain eol-style purity. */
+ char * p = value->data;
+ while (p = strchr(p, '\r'))
+ *p = ' ';
/* "svn:date" should be a valid date. */
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-28 12:44:18 CET