diff --git a/en_US.ISO8859-1/articles/committers-guide/article.sgml b/en_US.ISO8859-1/articles/committers-guide/article.sgml
index 1fa16d51de..7f1f750461 100644
--- a/en_US.ISO8859-1/articles/committers-guide/article.sgml
+++ b/en_US.ISO8859-1/articles/committers-guide/article.sgml
@@ -1124,4 +1124,66 @@
+
+
+ Miscellaneous questions
+
+
+
+
+ Why are trivial or cosmetic changes to files on a vendor
+ branch a bad idea?
+
+
+
+ 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.
+
+ 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.
+
+
+
+ 1.1.1.1
+ vendor import
+
+
+
+ 1.1.1.2
+ vendor import, +1000, -500 lines
+
+
+
+ 1.1.1.3
+ vendor import, +2000, -500 lines
+
+
+
+ 1.1.1.4
+ vendor import, +1000, -1000 lines
+
+
+
+ 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.
+
+ This is because the 1.2 delta is stored relative to 1.1.1.1,
+ not 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.
+
+ This is why we have such “hands
+ off” policies for src/contrib and other things that track
+ the vendor releases. This is why “typo fixes” in man
+ pages and spelling “corrections” are so strongly
+ discouraged for vendor code.
+
+
+
+
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 @@
+
+
+ Miscellaneous questions
+
+
+
+
+ Why are trivial or cosmetic changes to files on a vendor
+ branch a bad idea?
+
+
+
+ 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.
+
+ 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.
+
+
+
+ 1.1.1.1
+ vendor import
+
+
+
+ 1.1.1.2
+ vendor import, +1000, -500 lines
+
+
+
+ 1.1.1.3
+ vendor import, +2000, -500 lines
+
+
+
+ 1.1.1.4
+ vendor import, +1000, -1000 lines
+
+
+
+ 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.
+
+ This is because the 1.2 delta is stored relative to 1.1.1.1,
+ not 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.
+
+ This is why we have such “hands
+ off” policies for src/contrib and other things that track
+ the vendor releases. This is why “typo fixes” in man
+ pages and spelling “corrections” are so strongly
+ discouraged for vendor code.
+
+
+
+