Add a new "miscellaneous questions" section. The first question is "Why

are changes to files on the vendor branch a bad idea?", and the answer is
supplied by an (almost) verbatim excerpt from one of Peter Wemm's messages
to committers (<19991129055252.65D5E1C6D@overcee.netplex.com.au>).

1 files changed, 62 insertions, 0 deletions

diff --git a/en_US.ISO_8859-1/articles/committers-guide/article.sgml b/en_US.ISO_8859-1/articles/committers-guide/article.sgml
index 1fa16d51de..7f1f750461 100644
--- a/en_US.ISO_8859-1/articles/committers-guide/article.sgml
+++ b/en_US.ISO_8859-1/articles/committers-guide/article.sgml
@@ -1124,4 +1124,66 @@
       </qandadiv>
     </qandaset>
   </sect1>
+
+  <sect1>
+    <title>Miscellaneous questions</title>
+
+    <qandaset>
+      <qandaentry>
+	<question>
+	  <para>Why are trivial or cosmetic changes to files on a vendor
+	    branch a bad idea?</para>
+	</question>
+
+	<answer>
+	  <para>The RCS file format is quite braindead and certain operations
+	    to achieve things for CVS are hideously expensive for the
+	    repository.  Making changes to files on a vendor branch, thereby
+	    pulling the file off that branch, is one example of this.</para>
+
+	  <para>Suppose you have a file which was first imported on a vendor
+	    branch, and was then re-imported three times (still on the vendor
+	    branch) as the vendor makes updates to the file.</para>
+
+	  <segmentedlist>
+	    <seglistitem>
+	      <seg>1.1.1.1</seg>
+	      <seg>vendor import</seg>
+	    </seglistitem>
+
+	    <seglistitem>
+	      <seg>1.1.1.2</seg>
+	      <seg>vendor import, +1000, -500 lines</seg>
+	    </seglistitem>
+
+	    <seglistitem>
+	      <seg>1.1.1.3</seg>
+	      <seg>vendor import, +2000, -500 lines</seg>
+	    </seglistitem>
+
+	    <seglistitem>
+	      <seg>1.1.1.4</seg>
+	      <seg>vendor import, +1000, -1000 lines</seg>
+	    </seglistitem>
+	  </segmentedlist>
+
+	  <para>Now suppose that one of the FreeBSD committers makes a one
+	  line change to this file, causing it to go to version 1.2.  This
+	  causes it to leave the branch, resulting in 4,001 lines being added
+	  to the file's history, and 2,001 lines being deleted.</para>
+
+	  <para>This is because the 1.2 delta is stored relative to 1.1.1.1,
+	    <emphasis>not</emphasis> 1.1.1.4, and so the entire vendor history
+	    is duplicated in the 1.2 delta.   Now, repeat this for 2000 files
+	    in a large directory, it adds up a lot.</para>
+
+	  <para><emphasis>This</emphasis> is why we have such &ldquo;hands
+	    off&rdquo; policies for src/contrib and other things that track
+	    the vendor releases.  This is why &ldquo;typo fixes&rdquo; in man
+	    pages and spelling &ldquo;corrections&rdquo; are so strongly
+	    discouraged for vendor code.</para>
+	</answer>
+      </qandaentry>
+    </qandaset>
+  </sect1>
 </article>