The standard method for creating patches requires developers to:
- checkout the Subversion repository (or bring a copy up-to-date),
- make the necessary modifications to a working copy,
-- check with 'svn status' to see which files will be modified/added, and
+- check with 'svn status' to see which files will be modified/added, and
- use 'svn diff' to review the changes and produce a patch.
It is important to minimize the changes to only those lines that contain
<code>svn diff</code>. Overlapping patches will be discussed in the
next section.
-The remainder of this section provides
+The remainder of this section provides
@subsection primerpatchprops Subversion Properties
svn diff foo | unix2dos | patch -R
@endcode
-This is not a bug.
+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
work on the project voluntarily and without compensation for the time
that they spend doing these tasks.
+@section primerpatchguide Guidelines for Submitting Patches
+
+- Each patch file should contain:
+ - A commit description that describes all of the changes.
+ - A separator line that contains three hyphens: <code>---</code>
+ - A summary of the changes produced by diffstat (optional)
+ - Another separator line (optional)
+ - The actual patch contents, containing a single change.
+
+- Each patch series should include:
+ - A summary of the patches in the series.
+ - Logically-related patches that contain incremental changes.
+
*/
/** @file
This file contains the @ref primerpatches page.