subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: Editing svn:log property on file
Date Tue, 30 Oct 2012 16:19:11 GMT
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.s@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@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@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.)
> > > > > >
> > > >
> >

Mime
View raw message