os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

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

Browse source 
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>).
This commit is contained in:
Nik Clayton 2000-01-19 22:37:18 +00:00
parent 06b0a75aad
commit a8ab59b6bc
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=6399
2 changed files with 124 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

62
en_US.ISO8859-1/articles/committers-guide/article.sgml
View file

@ -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>

62
en_US.ISO_8859-1/articles/committers-guide/article.sgml
View file

@ -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>