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

Completely rewrite question 10.1 ("Why are cosmetic changes on the vendor

Browse source 
branch a bad idea?") with more correct information provided by Bruce.
This commit is contained in:
Nik Clayton 2001-04-27 10:07:52 +00:00
parent 6f122e0479
commit bb50fb63d7
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=9322
2 changed files with 36 additions and 108 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -19,7 +19,7 @@
</author>
</authorgroup>
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/articles/committers-guide/article.sgml,v 1.59 2001/04/07 18:22:32 obrien Exp $</pubdate>
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/articles/committers-guide/article.sgml,v 1.60 2001/04/08 17:26:41 nik Exp $</pubdate>
<copyright>
<year>1999</year>
@ -516,11 +516,11 @@
</itemizedlist>
<para>You'll almost certainly get a conflict because
of the <literal>$Id: article.sgml,v 1.60 2001-04-08 17:26:41 nik Exp $</literal> (or in FreeBSD's case,
of the <literal>$Id: article.sgml,v 1.61 2001-04-27 10:07:52 nik Exp $</literal> (or in FreeBSD's case,
<literal>$FreeBSD<!-- stop expansion -->$</literal>) lines, so you'll have to edit
the file to resolve the conflict (remove the marker lines and
the second <literal>$Id: article.sgml,v 1.60 2001-04-08 17:26:41 nik Exp $</literal> line, leaving the original
<literal>$Id: article.sgml,v 1.60 2001-04-08 17:26:41 nik Exp $</literal> line intact).</para>
the second <literal>$Id: article.sgml,v 1.61 2001-04-27 10:07:52 nik Exp $</literal> line, leaving the original
<literal>$Id: article.sgml,v 1.61 2001-04-27 10:07:52 nik Exp $</literal> line intact).</para>
</listitem>
<listitem>
@ -2022,58 +2022,22 @@ docs:Documentation Bug:nik:</programlisting>
</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>
<itemizedlist>
<listitem>
<para>From now on, every new vendor release of that file will
need to have patches merged in by hand.</para>
</listitem>
<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>
<listitem>
<para>From now on, every new vendor release of that file will
need to have patches <emphasis>verified</emphasis> by hand.</para>
</listitem>
<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
<quote>hands off</quote> policies for
<filename>src/contrib</filename> and other things that
track the vendor releases. This is why <quote>typo
fixes</quote> in man pages and spelling
<quote>corrections</quote> are so strongly discouraged for
vendor code.</para>
<listitem>
<para>The <option>-j</option> option doesn't work very well.
Ask &a.obrien; for horror stories.</para>
</listitem>
</itemizedlist>
</answer>
</qandaentry>