Srdan Dukic wrote on Tue, Oct 30, 2012 at 17:36:57 +1300: > Yes, it was the "svn:log" property on the revision (as opposed to the node) > which was causing the issue. Was able to modify it with the "propset" > command and it has allowed svnsync to continue the sync. > > So, the file to be patched is: > http://svn.apache.org/repos/asf/subversion/trunk/subversion/svnsync/sync.c > > Is it the section that's commented as "Normalize svn:* properties as > necessary." that the error's being thrown? >
No. That function just changes the line ending style; a local in-memory manipulation. The error is propagated by the commit editor after the validation code (on the server-side) raises it. The commit editor gets the revprops at the svn_ra_get_commit_editor3() call in main.c and the nodeprops via calls to its change_file_prop() and change_dir_prop() methods. See svn_delta_editor_t's docstring where it talks about possibly async error behaviour. If you consider sending a patch, please read http://subversion.apache.org/patches Thanks Daniel > -- > Srdan Dukic > > On 30 October 2012 17:21, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > > > IIRC svnsync would only complain about revisions add or modify an > > svn:log property --- other changes to files having that property (even > > with a bad value) should sync errorlessly. See validate_revision() in > > subversion/libsvn_repos/fs-wrap.c > > > > Anyway. I suggest you figure out a way to exclude "svn:log" node > > properties from the sync. If there is an easier way to do that than to > > patch change_file_prop() in subversion/svnsync/, I'm sure someone will > > suggest it. > > > > Srdan Dukic wrote on Tue, Oct 30, 2012 at 17:15:18 +1300: > > > Hmmm... yes indeed. This does seem to be the case, as the same developer > > > committed the same file, with the same log message in another location, > > and > > > this time the dump/load is not working. > > > > > > Even though the load doesn't throw any errors, when continuing with the > > > svnsync after loading, it starts complaining about UTF-8 again and won't > > > load the version. > > > > > > -- > > > Srdan Dukic > > > > > > On 30 October 2012 17:04, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > > > > > > > Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:58:01 +1300: > > > > > Checked it by examining the contents of the dump file (cat > > [dumpfile]). > > > > > Where I expected to see: > > > > > > > > > > client?\146s > > > > > > > > > > > > > Wrong expectation, dump files never include this syntax. > > > > > > > > > I instead got: > > > > > > > > > > client?s > > > > > > > > > > > > > This doesn't say whether it was a literal question mark (0x3F) in the > > > > file or not. > > > > > > > > > > > > > Then, after copying it over to the slave and running "load", without > > the > > > > > "--bypass-prop-validation" flag, the dump is loaded without any > > errors > > > > > complaining about the encoding of the properties. > > > > > > > > > > -- > > > > > Srdan Dukic > > > > > > > > > > On 30 October 2012 16:51, Daniel Shahaf <d...@daniel.shahaf.name> > > wrote: > > > > > > > > > > > Srdan Dukic wrote on Tue, Oct 30, 2012 at 16:45:36 +1300: > > > > > > > Thanks for that. Using svnadmin "dump" and then "load" worked. > > > > > > > > > > > > > > I didn't even have to pass the "--bypass-prop-validation" option > > to > > > > the > > > > > > > load command, as it seems the non-UTF8 symbols were converted to > > a > > > > "?" by > > > > > > > the dump command. > > > > > > > > > > > > How are you checking that? The 'dump' command doesn't know about > > UTF-8 > > > > > > requirements for property values; it should preserve arbitrary byte > > > > > > sequences. (In other words, the output of 'propget --strict | xxd' > > > > > > should be identical between master and slave.) > > > > > > > > > > > >
