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

Committer guide: remove merge information for branches older than 10.x

Browse source 
There are no such supported branches. Those that need to merge to such
branches can get the information from the documentation archive.
This commit is contained in:
Eitan Adler 2018-05-28 20:27:22 +00:00
parent 3e4070e36b
commit b8807f3369
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=51736
1 changed files with 0 additions and 143 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

143
en_US.ISO8859-1/articles/committers-guide/article.xml
View file

@ -1312,149 +1312,6 @@ You need a Passphrase to protect your secret key.</screen>
<screen>&prompt.user; svn merge -c <replaceable>r123456</replaceable> ^/stable/<replaceable>10</replaceable> releng/<replaceable>10.0</replaceable></screen>
</sect4>
<!-- FIXME: This probably needs to go away -->
<sect4 xml:id="oldmerge">
<title>Selecting the Source and Target for
<literal>stable/9</literal> and Older</title>
<para>For <literal>stable/9</literal> and earlier,
a different strategy was used, distributing mergeinfo
around the tree so that merges could be performed without
a complete checkout. This procedure proved extremely
error-prone, with the convenience of partial checkouts for
merges significantly outweighed by the complexity of
picking mergeinfo targets. The procedure below describes this
now-obsoleted process, which should be used
<emphasis>only for merges prior to
<literal>stable/10</literal></emphasis>.</para>
<para>Because of mergeinfo propagation, it is important to
choose the source and target for the merge carefully to
minimise property changes on unrelated directories.</para>
<para>The rules for selecting the merge target (the
directory where the changes are being merged to) can be
summarized:</para>
<orderedlist>
<listitem>
<para>Never merge directly to a file.</para>
</listitem>
<listitem>
<para>Never, ever merge directly to a file.</para>
</listitem>
<listitem>
<para><emphasis>Never, ever, ever</emphasis> merge
directly to a file.</para>
</listitem>
<listitem>
<para>Changes to kernel code are merged to
<filename>sys/</filename>. For instance, a change to
the &man.ichwd.4; driver is merged to
<filename>sys/</filename>, not
<filename>sys/dev/ichwd/</filename>. Likewise, a
change to the TCP/IP stack is merged to
<filename>sys/</filename>, not
<filename>sys/netinet/</filename>.</para>
</listitem>
<listitem>
<para>Changes to code under <filename>etc/</filename>
is merged at <filename>etc/</filename>, not
below it.</para>
</listitem>
<listitem>
<para>Changes to vendor code (code in
<filename>contrib/</filename>,
<filename>crypto/</filename> and so on) are
merged to the directory where vendor imports happen.
For instance, a change to
<filename>crypto/openssl/util/</filename> is
merged to <filename>crypto/openssl/</filename>. This
is rarely an issue, however, since changes to vendor
code are usually merged wholesale.</para>
</listitem>
<listitem>
<para>Changes to userland programs should as a general
rule be merged to the directory that contains the
Makefile for that program. For instance, a change to
<filename>usr.bin/xlint/arch/i386/</filename>
is merged to
<filename>usr.bin/xlint/</filename>.</para>
</listitem>
<listitem>
<para>Changes to userland libraries should as a general
rule be merged to the directory that contains the
Makefile for that library. For instance, a change to
<filename>lib/libc/gen/</filename> should be merged to
<filename>lib/libc/</filename>.</para>
</listitem>
<listitem>
<para>There may be cases where it makes sense to deviate
from the rules for userland programs and libraries.
For instance, everything under
<filename>lib/libpam/</filename> is merged to
<filename>lib/libpam/</filename>, even though the
library itself and all of the modules each have their
own Makefile.</para>
</listitem>
<listitem>
<para>Changes to manual pages are merged to
<filename>share/man/man<replaceable>N</replaceable>/</filename>,
for the appropriate value of
<literal>N</literal>.</para>
</listitem>
<listitem>
<para>Other changes to <filename>share/</filename>
are merged to the appropriate subdirectory and
not to <filename>share/</filename> directly.</para>
</listitem>
<listitem>
<para>Changes to a top-level file in the source tree
such as <filename>UPDATING</filename> or
<filename>Makefile.inc1</filename> are merged
directly to that file rather than to the root of the
whole tree. Yes, this is an exception to the first
three rules.</para>
</listitem>
<listitem>
<para>When in doubt, ask.</para>
</listitem>
</orderedlist>
<para>If a merge changes several places at once
(for instance, changing a kernel interface and every
userland program that uses it), merge each target
separately, then commit them together. For instance, if
merging a revision that changed a kernel
<acronym>API</acronym> and updated all the userland bits
that used that <acronym>API</acronym>, merge the
kernel change to sys, and the userland bits to the
appropriate userland directories, then commit all of these
in one go.</para>
<para>The source will almost invariably be the same as the
target. For instance, always merge
<filename>stable/7/lib/libc/</filename> from
<filename>head/lib/libc/</filename>. The only exception
would be when merging changes to code that has moved in
the source branch but not in the parent branch. For
instance, a change to &man.pkill.1; would be merged from
<filename>bin/pkill/</filename> in head to
<filename>usr.bin/pkill/</filename> in stable/7.</para>
</sect4>
<sect4>
<title>Preparing the Merge Target</title>