-The remainder of this section provides
-
-@subsection primerpatchprops Subversion Properties
-
-The Subversion attributes of files can be examined with commands like the
-following: @par
-@verbatim
-$ svn pl README
-Properties on 'README':
- svn:eol-style
-$ svn pl tools/rlink_make_speed_table/rlink_make_speed_table.pl
-Properties on 'tools/rlink_make_speed_table/rlink_make_speed_table.pl':
- svn:executable
- svn:eol-style
-$
-@endverbatim
-
-@subsection primerpatchpropcrlf Native Line-endings
-
-Subversion checks out files marked with the attribute @c svn:eol-style
-set to @c native such that these files contain the default line ending
-style of the current host ('\\n' or '\\r\\n'). By using the proper line
-endings for different platforms, two different byte streams for the same
-file will be produced.
-
-@subsection primerpatchwincrlf Windows Patching Problems
-
-Because of the line-ending functionality, it may be correct when a fresh
-patch does not apply cleanly on the Windows platform. This is because
-patches are created by SVN with UNIX line endings, so the context and
-changes will not appear to match the files with Windows line endings.
-
-In other words, the following command may @b not succeed because @c foo
-has its @c svn:eol-style property set to @c native: @par
-@code
-svn diff foo | patch -R
-@endcode
-
-The following series of commands will work: @par
-@code
-svn diff foo | unix2dos | patch -R
-@endcode
-
-This is not a bug.
-
-@todo Does Subversion's treatment of line-endings for files marked with
-svn:eol-style=native continue to pose the problems described here, or
-has this been magically solved?
+@todo Does git's treatment of line-endings behave sanely?
+Basically, the repository should use newlines internally,
+and convert to/from CRLF on Windows etc.