diff --git a/en_US.ISO8859-1/articles/committers-guide/article.xml b/en_US.ISO8859-1/articles/committers-guide/article.xml index 9b72bca224..6babaf08e7 100644 --- a/en_US.ISO8859-1/articles/committers-guide/article.xml +++ b/en_US.ISO8859-1/articles/committers-guide/article.xml @@ -1312,149 +1312,6 @@ You need a Passphrase to protect your secret key. &prompt.user; svn merge -c r123456 ^/stable/10 releng/10.0 - - - Selecting the Source and Target for - <literal>stable/9</literal> and Older - - For stable/9 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 - only for merges prior to - stable/10. - - Because of mergeinfo propagation, it is important to - choose the source and target for the merge carefully to - minimise property changes on unrelated directories. - - The rules for selecting the merge target (the - directory where the changes are being merged to) can be - summarized: - - - - Never merge directly to a file. - - - - Never, ever merge directly to a file. - - - - Never, ever, ever merge - directly to a file. - - - - Changes to kernel code are merged to - sys/. For instance, a change to - the &man.ichwd.4; driver is merged to - sys/, not - sys/dev/ichwd/. Likewise, a - change to the TCP/IP stack is merged to - sys/, not - sys/netinet/. - - - - Changes to code under etc/ - is merged at etc/, not - below it. - - - - Changes to vendor code (code in - contrib/, - crypto/ and so on) are - merged to the directory where vendor imports happen. - For instance, a change to - crypto/openssl/util/ is - merged to crypto/openssl/. This - is rarely an issue, however, since changes to vendor - code are usually merged wholesale. - - - - 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 - usr.bin/xlint/arch/i386/ - is merged to - usr.bin/xlint/. - - - - 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 - lib/libc/gen/ should be merged to - lib/libc/. - - - - There may be cases where it makes sense to deviate - from the rules for userland programs and libraries. - For instance, everything under - lib/libpam/ is merged to - lib/libpam/, even though the - library itself and all of the modules each have their - own Makefile. - - - - Changes to manual pages are merged to - share/man/manN/, - for the appropriate value of - N. - - - - Other changes to share/ - are merged to the appropriate subdirectory and - not to share/ directly. - - - - Changes to a top-level file in the source tree - such as UPDATING or - Makefile.inc1 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. - - - - When in doubt, ask. - - - - 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 - API and updated all the userland bits - that used that API, merge the - kernel change to sys, and the userland bits to the - appropriate userland directories, then commit all of these - in one go. - - The source will almost invariably be the same as the - target. For instance, always merge - stable/7/lib/libc/ from - head/lib/libc/. 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 - bin/pkill/ in head to - usr.bin/pkill/ in stable/7. - - Preparing the Merge Target