Re: Editing svn:log property on file

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?

-- 
Srdan Dukic
On 30 October 2012 17:21, Daniel Shahaf <d.s_at_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.s_at_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.s_at_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.)
> > > > >
> > >
>