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.) > > > >
