On 14.01.2019 14:10, julianf...@apache.org wrote: > Author: julianfoad > Date: Mon Jan 14 13:10:45 2019 > New Revision: 1851244 > > URL: http://svn.apache.org/viewvc?rev=1851244&view=rev > Log: > * subversion/include/svn_client.h > (svn_client_blame_receiver4_t): Improve doc string. > > Modified: > subversion/trunk/subversion/include/svn_client.h > > Modified: subversion/trunk/subversion/include/svn_client.h > URL: > http://svn.apache.org/viewvc/subversion/trunk/subversion/include/svn_client.h?rev=1851244&r1=1851243&r2=1851244&view=diff > ============================================================================== > --- subversion/trunk/subversion/include/svn_client.h (original) > +++ subversion/trunk/subversion/include/svn_client.h Mon Jan 14 13:10:45 2019 > @@ -739,8 +739,7 @@ typedef svn_error_t *(*svn_client_get_co > /** Callback type used by svn_client_blame6() to notify the caller > * that line @a line_no of the blamed file was last changed in @a revision > * which has the revision properties @a rev_props, and that the contents were > - * @a line. The @a line content is delivered as is. It is up to the client to > - * determine the encoding. The line does not contain the CR/LF at the end. > + * @a line. > * > * @a start_revnum and @a end_revnum contain the start and end revision > * number of the entire blame operation, as determined from the repository > @@ -759,10 +758,20 @@ typedef svn_error_t *(*svn_client_get_co > * will be true if the reason there is no blame information is that the line > * was modified locally. In all other cases @a local_change will be false. > * > - * @note the line contents are processed by @ref svn_subst_stream_translated > - * to convert newlines. The lines are then split on newlines. > - * Clients must be aware of this when dealing with different encodings of > - * the file/line. > + * Character Encoding and Line Splitting: > + * > + * It is up to the client to determine the character encoding. The @a line > + * content is delivered without any encoding conversion. The line splitting > + * is designed to work with ASCII-compatible encodings including UTF-8. Any > + * of the byte sequences LF ("\n"), CR ("\n"), CR LF ("\r\n") ends a line > + * and is not included in @a line. The @a line content can include all other > + * byte values including zero (ASCII NUL). > + * > + * @note That is how line splitting is done on the final file content, from > + * which this callback is driven. It is not entirely clear whether the line > + * splitting used to calculate diffs between each revision and assign a > + * revision number to each line is exactly compatible with this in all cases. > + *
I was really hoping we wouldn't duplicate documentation like this ... -- Brane
