From owner-svn-doc-all@FreeBSD.ORG Sun Jun 30 01:00:51 2013 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 38ED3A07; Sun, 30 Jun 2013 01:00:51 +0000 (UTC) (envelope-from wblock@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id 2AF9C1BE5; Sun, 30 Jun 2013 01:00:51 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r5U10p1Z081624; Sun, 30 Jun 2013 01:00:51 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id r5U10pVY081623; Sun, 30 Jun 2013 01:00:51 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201306300100.r5U10pVY081623@svn.freebsd.org> From: Warren Block Date: Sun, 30 Jun 2013 01:00:51 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r42087 - head/en_US.ISO8859-1/articles/committers-guide X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 01:00:51 -0000 Author: wblock Date: Sun Jun 30 01:00:50 2013 New Revision: 42087 URL: http://svnweb.freebsd.org/changeset/doc/42087 Log: Whitespace-only changes. Translators, please ignore. Modified: head/en_US.ISO8859-1/articles/committers-guide/article.xml Modified: head/en_US.ISO8859-1/articles/committers-guide/article.xml ============================================================================== --- head/en_US.ISO8859-1/articles/committers-guide/article.xml Sat Jun 29 22:59:48 2013 (r42086) +++ head/en_US.ISO8859-1/articles/committers-guide/article.xml Sun Jun 30 01:00:50 2013 (r42087) @@ -83,16 +83,15 @@ src/ Subversion Root - - svn+ssh://svn+ssh://svn.FreeBSD.org/base (see also ). + doc/ Subversion Root - - svn+ssh://svn+ssh://svn.FreeBSD.org/doc (see also ). @@ -100,8 +99,7 @@ ports/ Subversion Root - - svn+ssh://svn+ssh://svn.FreeBSD.org/ports (see also ). @@ -128,8 +126,7 @@ reports /home/core/public/monthly-reports on the FreeBSD.org - cluster. - + cluster. @@ -147,32 +144,35 @@ stable/8 (8.X-STABLE), stable/9 (9.X-STABLE), - head (-CURRENT) - + head (-CURRENT) - It is required that you use &man.ssh.1; - to connect to the project hosts. - If you do - not know anything about &man.ssh.1;, please see - . + It is required that you use &man.ssh.1; to connect to the + project hosts. If you do not know anything about &man.ssh.1;, + please see . Useful links: - FreeBSD - Project Internal Pages + + FreeBSD + Project Internal Pages + - + FreeBSD Project - Hosts + Hosts + - + FreeBSD Project - Administrative Groups + Administrative Groups + @@ -238,7 +238,7 @@ Policy for <filename>doc/</filename> Committer Activity - in <filename>src/</filename> + in src/ doc committers may commit documentation @@ -274,13 +274,13 @@ operation of the version control systems in use. Traditionally this was CVS. Subversion is used for the src tree as of May 2008, the doc/www tree as of - May 2012 and the ports tree as of July 2012. - + May 2012 and the ports tree as of July + 2012. There - is a list of things missing in Subversion when compared to CVS - . The notes at + is a list of things missing in Subversion when compared to + CVS. The notes at might also be useful. @@ -489,26 +489,29 @@ - /head/ - which corresponds to HEAD, also known as - -CURRENT. - + /head/ which corresponds to + HEAD, also known as + -CURRENT. + /stable/n which corresponds to RELENG_n. + /releng/n.n which corresponds to RELENG_n_n. + /release/n.n.n which corresponds to RELENG_n_n_n_RELEASE. + /vendor* is the vendor branch import work area. This directory itself does not @@ -532,8 +535,8 @@ Layout In svn+ssh://svn.freebsd.org/doc, - doc refers to the repository root of the - source tree. + doc refers to the repository root of + the source tree. In general, most &os; Documentation Project work will be done within the head/ branch of the @@ -580,17 +583,20 @@ - /branches/RELENG_n_n_n - which corresponds to - RELENG_n_n_n + /branches/RELENG_n_n_n + which corresponds to + RELENG_n_n_n is used to merge back security updates in preparation for a release. + /tags/RELEASE_n_n_n - which corresponds to RELEASE_n_n_n + which corresponds to + RELEASE_n_n_n represents a release tag of the ports tree. + /tags/RELEASE_n_EOL represents the end of life tag of a specific &os; @@ -615,9 +621,9 @@ &prompt.user; svn help - Additional information can be found in the - Subversion Book. + Additional information can be found in the + Subversion + Book. @@ -717,7 +723,8 @@ &prompt.user; svn status - To show local changes and files that are out-of-date do: + To show local changes and files that are out-of-date + do: &prompt.user; svn status --show-updates @@ -766,9 +773,8 @@ svn rm --keep-local for just added files, fix your config file and re-add them again. The initial config file is created when you first run a svn - command, even something as simple as svn - help. - + command, even something as simple as + svn help. Files are added to a @@ -1079,21 +1085,23 @@ - If branch/foo/bar/ does not - already have a mergeinfo record, but a direct ancestor - (for instance, branch/foo/) does, - then that record will be propagated down to + If + branch/foo/bar/ + does not already have a mergeinfo record, but a direct + ancestor (for instance, + branch/foo/) + does, then that record will be propagated down to branch/foo/bar/ - before information - about the current merge is recorded. + before information about the current merge is + recorded. + Information about the current merge will not be propagated back up that ancestor. + If a direct descendant of branch/foo/bar/ (for @@ -1132,13 +1140,16 @@ 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 should be merged to sys/. For @@ -1151,12 +1162,14 @@ not sys/netinet/. + Changes to code under etc/ should be merged at etc/, not below it. + Changes to vendor code (code in contrib/, + Changes to userland programs should as a general rule be merged to the directory that contains the @@ -1178,6 +1192,7 @@ should be merged to usr.bin/xlint/. + Changes to userland libraries should as a general rule be merged to the directory that contains the @@ -1186,6 +1201,7 @@ should be merged to lib/libc/. + There may be cases where it makes sense to deviate from the rules for userland programs and libraries. @@ -1195,12 +1211,15 @@ even though the library itself and all of the modules each have their own Makefile. + - Changes to manual pages should be merged to Changes to manual pages should be merged to + share/man/manN/, for the appropriate value of N. + Other changes to share/ should be merged @@ -1208,6 +1227,7 @@ share/ directly. + Changes to a top-level file in the source tree such as UPDATING or @@ -1216,6 +1236,7 @@ whole tree. Yes, this is an exception to the first three rules. + When in doubt, ask. @@ -1332,21 +1353,26 @@ $target - head/$source:$P,$Q,$R Practical Example - As a practical example, consider the following scenario: - The changes to netmap.4 in r238987 is - to be merged from CURRENT to 9-STABLE. The file resides in - head/share/man/man4 and - according to this - is also where to do the merge. Note that in this example - all paths are relative to the top of the svn repository. - for more information on the directory layout, see + + As a practical example, consider the following + scenario: The changes to netmap.4 + in r238987 is to be merged from CURRENT to 9-STABLE. + The file resides in head/share/man/man4 and + according to + this is also where to do the merge. Note that in this + example all paths are relative to the top of the svn + repository. for more information on the directory + layout, see . - The first step is to inspect the existing mergeinfo. + + The first step is to inspect the existing + mergeinfo. &prompt.user; svn propget svn:mergeinfo -R stable/9/share/man/man4 - Take a quick note of how it looks before moving on to the next - step; doing the actual merge: + Take a quick note of how it looks before moving on + to the next step; doing the actual merge: &prompt.user; svn merge -c r238987 svn+ssh://svn.freebsd.org/base/head/share/man/man4 stable/9/share/man/man4 --- Merging r238987 into 'stable/9/share/man/man4': @@ -1355,11 +1381,11 @@ U stable/9/share/man/man4/netmap.4 'stable/9/share/man/man4': U stable/9/share/man/man4 - Check that the revision number of the merged revision - has been added. Once this is verified, the only thing left - is the actual commit. - - &prompt.user; svn commit stable/9/share/man/man4 + Check that the revision number of the merged + revision has been added. Once this is verified, the + only thing left is the actual commit. + + &prompt.user; svn commit stable/9/share/man/man4 @@ -1419,24 +1445,26 @@ U stable/9/share/man/man4/netmap.4 Vendor Imports with <acronym>SVN</acronym> - Please read this entire section before starting a vendor - import. + Please read this entire section before starting a + vendor import. - Patches to vendor code fall into two categories: + Patches to vendor code fall into two + categories: Vendor patches: these are patches that have been - issued by the vendor, or that have been extracted from - the vendor's version control system, which address - issues which in your opinion cannot wait until the next - vendor release. + issued by the vendor, or that have been extracted from + the vendor's version control system, which address + issues which in your opinion cannot wait until the + next vendor release. + &os; patches: these are patches that modify the - vendor code to address &os;-specific issues. + vendor code to address &os;-specific issues. @@ -1446,17 +1474,18 @@ U stable/9/share/man/man4/netmap.4 Vendor patches should be committed to the vendor - branch, and merged from there to head. If the patch - addresses an issue in a new release that is currently - being imported, it must not be - committed along with the new release: the release must - be imported and tagged first, then the patch can be - applied and committed. There is no need to re-tag the - vendor sources after committing the patch. + branch, and merged from there to head. If the patch + addresses an issue in a new release that is currently + being imported, it must not be + committed along with the new release: the release must + be imported and tagged first, then the patch can be + applied and committed. There is no need to re-tag the + vendor sources after committing the patch. + &os; patches should be committed directly to - head. + head. @@ -1509,22 +1538,22 @@ U stable/9/share/man/man4/netmap.4 as necessary. Disabling keyword expansion is recommended, as it makes no sense on unmodified vendor code and in some cases it can even be harmful. - OpenSSH, for example, includes - two files that originated with &os; and still contain the - original version tags. To do this: + OpenSSH, for example, + includes two files that originated with &os; and still + contain the original version tags. To do this: &prompt.user; svn propdel svn:keywords -R . &prompt.root; svn commit + Bootstrapping Merge History If importing for the first time after the switch to - Subversion, bootstrap - svn:mergeinfo on the target directory - in the main tree to the revision that corresponds - to the last related change to the vendor tree, prior to - importing new sources: + Subversion, bootstrap svn:mergeinfo + on the target directory in the main tree to the revision + that corresponds to the last related change to the + vendor tree, prior to importing new sources: &prompt.user; cd head/contrib/pf &prompt.user; svn merge --record-only svn+ssh://svn.freebsd.org/base/vendor/pf/dist@180876 . @@ -1543,11 +1572,11 @@ U stable/9/share/man/man4/netmap.4 Preparing the Vendor Sources - Unlike in CVS where only the needed - parts were imported into the vendor tree to avoid bloating - the main tree, Subversion is able to store a full - distribution in the vendor tree. So, import everything, - but merge only what is required. + Unlike in CVS where only the + needed parts were imported into the vendor tree to avoid + bloating the main tree, Subversion is able to store a + full distribution in the vendor tree. So, import + everything, but merge only what is required. A svn add is required to add any files that were added since the last vendor import, and @@ -1563,12 +1592,13 @@ U stable/9/share/man/man4/netmap.4 &prompt.user; find . -type f | cut -c 3- | sort >../new With these two files, - comm -23 ../old ../new - will list removed files (files only in - old), while - comm -13 ../old ../new - will list added files only in new. + comm -23 ../old ../new will list + removed files (files only in old), + while comm -13 ../old ../new will + list added files only in + new. + Importing into the Vendor Tree @@ -1584,17 +1614,18 @@ U stable/9/share/man/man4/netmap.4 &prompt.user; comm -23 ../old ../new | xargs svn rm &prompt.user; comm -13 ../old ../new | xargs svn --parents add - If any directories were removed, they will have to be - svn rmed manually. Nothing will break - if they are not, but they will remain in the tree. + If any directories were removed, they will have to + be svn rmed manually. Nothing will + break if they are not, but they will remain in the + tree. - Check properties on any new files. All text files + Check properties on any new files. All text files should have svn:eol-style set to native. All binary files should have svn:mime-type set to application/octet-stream unless there - is a more appropriate media type. Executable files should - have svn:executable set to + is a more appropriate media type. Executable files + should have svn:executable set to *. No other properties should exist on any file in the tree. @@ -1619,13 +1650,15 @@ U stable/9/share/man/man4/netmap.4 needed. If creating the tag in the working copy of the tree, - svn:mergeinfo results must be removed: + svn:mergeinfo results must be + removed: &prompt.user; cd vendor/pf &prompt.user; svn cp dist 4.3 &prompt.user; svn propdel svn:mergeinfo -R 4.3 + Merging to Head @@ -1634,8 +1667,8 @@ U stable/9/share/man/man4/netmap.4 &prompt.user; svn merge --accept=postpone svn+ssh://svn.freebsd.org/base/vendor/pf/dist . The --accept=postpone tells - Subversion that it should not complain because merge conflicts - will be taken care of manually. + Subversion that it should not complain because merge + conflicts will be taken care of manually. It is necessary to resolve any merge conflicts. This process is the same in SVN as in @@ -1643,7 +1676,8 @@ U stable/9/share/man/man4/netmap.4 Make sure that any files that were added or removed in the vendor tree have been properly added or removed in the - main tree. To check diffs against the vendor branch: + main tree. To check diffs against the vendor + branch: &prompt.user; svn diff --no-diff-deleted --old=svn+ssh://svn.freebsd.org/base/vendor/pf/dist --new=. @@ -1659,13 +1693,15 @@ U stable/9/share/man/man4/netmap.4 Subversion, there is no concept of on or off the vendor branch. If a file that previously had local modifications, to make it not show up in diffs in the - vendor tree, all that has to be done is remove any left-over - cruft like &os; version tags, which is much easier. + vendor tree, all that has to be done is remove any + left-over cruft like &os; version tags, which is much + easier. If any changes are required for the world to build with the new sources, make them now, and keep testing until everything builds and runs perfectly. + Committing the Vendor Import @@ -1694,11 +1730,11 @@ U stable/9/share/man/man4/netmap.4 &prompt.user; svn mkdir byacc/dist Now, import the sources into the - dist directory. Once - the files are in place, svn add the new - ones, then svn commit and tag the - imported version. To save time and bandwidth, direct remote - committing and tagging is possible: + dist directory. + Once the files are in place, svn add + the new ones, then svn commit and tag + the imported version. To save time and bandwidth, + direct remote committing and tagging is possible: &prompt.user; svn cp -m "Tag byacc 20120115" $FSVN/vendor/byacc/dist $FSVN/vendor/byacc/20120115 @@ -1715,9 +1751,9 @@ U stable/9/share/man/man4/netmap.4 possible. - + - + Reverting a Commit Reverting a commit to a previous version is fairly @@ -1906,8 +1942,8 @@ U stable/9/share/man/man4/netmap.4 Do not remove and re-add the same file in a single commit as this will break the CVS exporter. - Speeding up svn is - possible by adding the following to ~/.ssh/config: + Speeding up svn is possible by adding the following to + ~/.ssh/config: Host * ControlPath ~/.ssh/sockets/master-%l-%r@%h:%p @@ -1919,10 +1955,10 @@ ControlPersist yes Checking out a working copy with a stock Subversion client without &os;-specific patches - (OPTIONS_SET=FREEBSD_TEMPLATE) will mean that - $FreeBSD$ tags will not be - expanded. Once the correct version has been installed, trick - Subversion into expanding them like so: + (OPTIONS_SET=FREEBSD_TEMPLATE) will mean + that $FreeBSD$ tags will not + be expanded. Once the correct version has been installed, + trick Subversion into expanding them like so: &prompt.user; svn propdel -R svn:keywords . &prompt.user; svn revert -R . @@ -1934,10 +1970,10 @@ ControlPersist yes Conventions and Traditions - As a new developer there are a number of things you should do - first. The first set is specific to committers only. (If you are - not a committer, e.g., have GNATS-only access, then your mentor needs - to do these things for you.) + As a new developer there are a number of things you should + do first. The first set is specific to committers only. (If + you are not a committer, e.g., have GNATS-only access, then your + mentor needs to do these things for you.) Guidelines for Committers @@ -1952,130 +1988,139 @@ ControlPersist yes If you have been given commit rights to one or more of the repositories: - - - Add your author entity to - head/share/xml/authors.ent; - this should be done first since an omission of this commit will - cause the next commits to break the doc/ build. - - This is a relatively easy task, but remains a good first test of - your version control skills. - - - New files that do not have the - FreeBSD=%H svn:keywords - property will be rejected when attempting to commit them to the - repository. Be sure to read - regarding adding and removing files, in addition - to verifying that ~/.subversion/config - contains the necessary "auto-props" - entries from auto-props.txt mentioned - there. - - - - Do not forget to get mentor approval for these patches! - - - - - - Also add your author entity to - head/share/xml/developers.ent. - - - - Add yourself to the Developers section of - the Contributors List - (head/en_US.ISO8859-1/articles/contributors/contrib.committers.xml) and remove yourself from the Additional - Contributors section (head/en_US.ISO8859-1/articles/contributors/contrib.additional.xml). - Please note that entries are sorted by last name. - + + + Add your author entity to + head/share/xml/authors.ent; this + should be done first since an omission of this commit will + cause the next commits to break the doc/ build. + + This is a relatively easy task, but remains a good + first test of your version control skills. + + + New files that do not have the + FreeBSD=%H + svn:keywords property will be + rejected when attempting to commit them to the + repository. Be sure to read + regarding + adding and removing files, in addition to verifying that + ~/.subversion/config contains the + necessary "auto-props" entries from + auto-props.txt mentioned + there. + + + + Do not forget to get mentor approval for these + patches! + + - - Add an entry for yourself to - head/share/xml/news.xml. Look for the other - entries that look like A new committer and follow the - format. - + + Also add your author entity to + head/share/xml/developers.ent. + - - You should add your PGP or GnuPG key to - head/share/pgpkeys (and if you do not - have a key, you should create one). Do not forget to commit - the updated head/share/pgpkeys/pgpkeys.ent - and head/share/pgpkeys/pgpkeys-developers.xml. - Please note that entries are sorted by last name. + + Add yourself to the Developers section + of the Contributors + List + (head/en_US.ISO8859-1/articles/contributors/contrib.committers.xml) + and remove yourself from the + Additional Contributors section + (head/en_US.ISO8859-1/articles/contributors/contrib.additional.xml). + Please note that entries are sorted by last name. + - &a.des; has - written a shell script (head/share/pgpkeys/addkey.sh) to make this extremely simple. See the - README - file for more information. + + Add an entry for yourself to + head/share/xml/news.xml. Look for + the other entries that look like + A new committer and follow the + format. + - - It is important to have an up-to-date PGP/GnuPG key in - the Handbook, since the key may be required for positive - identification of a committer, e.g., by the &a.admins; for - account recovery. A complete keyring of FreeBSD.org users is available - for download from http://www.FreeBSD.org/doc/pgpkeyring.txt. - - + + You should add your PGP or GnuPG key to + head/share/pgpkeys (and if you do not + have a key, you should create one). Do not forget to + commit the updated + head/share/pgpkeys/pgpkeys.ent and + head/share/pgpkeys/pgpkeys-developers.xml. + Please note that entries are sorted by last name. + + &a.des; has written a shell script + (head/share/pgpkeys/addkey.sh) to + make this extremely simple. See the README + file for more information. + + + It is important to have an up-to-date PGP/GnuPG key + in the Handbook, since the key may be required for + positive identification of a committer, e.g., by the + &a.admins; for account recovery. A complete keyring of + FreeBSD.org users is + available for download from http://www.FreeBSD.org/doc/pgpkeyring.txt. + + - - Add an entry for yourself to - src/share/misc/committers-repository.dot, - where repository is either doc, ports or src, depending on the commit privileges - you obtained. - + + Add an entry for yourself to + src/share/misc/committers-repository.dot, + where repository is either doc, ports or src, depending on + the commit privileges you obtained. + - - Some people add an entry for themselves to - ports/astro/xearth/files/freebsd.committers.markers. - + + Some people add an entry for themselves to + ports/astro/xearth/files/freebsd.committers.markers. + - - Some people add an entry for themselves to - src/usr.bin/calendar/calendars/calendar.freebsd. - + + Some people add an entry for themselves to + src/usr.bin/calendar/calendars/calendar.freebsd. + - - If you already have an account at the &os; wiki, - make sure your mentor moves you from the - Contributors group - to the - Developers group. - Otherwise, consider signing up for an account so you can publish - projects and ideas you are working on. - + + If you already have an account at the + &os; wiki, + make sure your mentor moves you from the Contributors + group to the Developers + group. Otherwise, consider signing up for an + account so you can publish projects and ideas you are + working on. + - - Once you get access to the wiki, you may - add yourself to the How We Got - Here and Irc Nicks - pages. - + + Once you get access to the wiki, you may add yourself + to the + How We + Got Here and + Irc + Nicks pages. + - - If you subscribe to &a.svn-src-all.name;, - &a.svn-ports-all.name; or &a.svn-doc-all.name;, - you will probably want to unsubscribe to avoid receiving duplicate - copies of commit messages and their followups. - - + + If you subscribe to &a.svn-src-all.name;, + &a.svn-ports-all.name; or &a.svn-doc-all.name;, you will + probably want to unsubscribe to avoid receiving duplicate + copies of commit messages and their followups. + + - - All src commits should go to - &os.current; first before being merged to &os.stable;. No major - new features or high-risk modifications should be made to the - &os.stable; branch. - + + All src commits should go to + &os.current; first before being merged to &os.stable;. No + major new features or high-risk modifications should be made + to the &os.stable; branch. + @@ -2083,69 +2128,72 @@ ControlPersist yes Whether or not you have commit rights: - - - Introduce yourself to the other developers, otherwise no one - will have any idea who you are or what you are working on. You do - not have to write a comprehensive biography, just write a paragraph - or two about who you are and what you plan to be working on as a - developer in FreeBSD. (You should also mention who your mentor - will be). Email this to the &a.developers; and you will - be on your way! - + + + Introduce yourself to the other developers, otherwise + no one will have any idea who you are or what you are + working on. You do not have to write a comprehensive + biography, just write a paragraph or two about who you are + and what you plan to be working on as a developer in + FreeBSD. (You should also mention who your mentor will + be). Email this to the &a.developers; and you will be on + your way! + - - Log into hub.FreeBSD.org and create a - /var/forward/user - (where user is your username) file - containing the e-mail address where you want mail addressed to - yourusername@FreeBSD.org to be forwarded. - This includes all of the commit messages as well as any other mail - addressed to the &a.committers; and the &a.developers;. Really - large mailboxes which have taken up permanent residence on - hub often get accidentally truncated - without warning, so forward it or read it and you will not lose - it. - - Due to the severe load dealing with SPAM places on - the central mail servers that do the mailing list processing - the front-end server does do some basic checks and will - drop some messages based on these checks. At the moment - proper DNS information for the connecting host is the only - check in place but that may change. Some people blame these - checks for bouncing valid email. If you want these checks - turned off for your email you can place a file named - .spam_lover in your home directory - on freefall.FreeBSD.org to - disable the checks for your email. - - + + Log into hub.FreeBSD.org and create a + /var/forward/user + (where user is your username) + file containing the e-mail address where you want mail + addressed to + yourusername@FreeBSD.org to be + forwarded. This includes all of the commit messages as + well as any other mail addressed to the &a.committers; and + the &a.developers;. Really large mailboxes which have + taken up permanent residence on hub often + get accidentally truncated without warning, + so forward it or read it and you will not lose it. + + Due to the severe load dealing with SPAM places on the *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***