dev-manual: Edits to the "Working in a Team Environment" section.

Fixes YOCTO #3274

Applied various review edits from Richard Purdie.  Additionally,
I ran a spell-check on the chapter and caught some typos.
I fixed these as necessary.

(From yocto-docs rev: 794a13d26bb7a9e268b16f809158a6af58cc3ce8)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

documentation/dev-manual/dev-manual-newbie.xml

@@ -174,9 +174,10 @@
                         would the usual cross-development toolchain so that
                         all developers can meet minimum version requirements
                         on most distributions.</para></listitem>
-                    <listitem><para>Use a small number of high performance
+                    <listitem><para>Use a small number of shared,
-                        systems for testing purposes (e.g. dual six core Xeons
+                        high performance systems for testing purposes
-                        with 24GB RAM and plenty of disk space).
+                        (e.g. dual six core Xeons with 24GB RAM and plenty of
+                        disk space).
                         Developers can use these systems for wider, more
                         extensive testing while they continue to develop
                         locally using their primary development system.
@@ -187,20 +188,26 @@
     </section>
 
     <section id='best-practices-source-control-management'>
-        <title>Source Control Manangement (SCM)</title>
+        <title>Source Control Management (SCM)</title>
 
         <para>
             Keeping your
             <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
             and any software you are developing under the
             control of an SCM system that is compatible
-            with the OpenEmbedded build system is adviseable.
+            with the OpenEmbedded build system is advisable.
-            Of the two SCMs available (Git or Subversion), the
+            Of the SCMs BitBake supports, the
             Yocto Project team strongly recommends using
             <link linkend='git'>Git</link>.
             Git is a distributed system that is easy to backup
             (each checkout is a backup in itself), allows you to work
-            remotely, and then connect back to the infrastructue.
+            remotely, and then connect back to the infrastructure.
+            <note>
+                For information about BitBake and SCMs, see the
+                BitBake manual located in the
+                <filename>bitbake/doc/manual</filename> directory of the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            </note>
         </para>
 
         <para>
@@ -211,7 +218,7 @@
             <filename>gitolite</filename> with <filename>cgit</filename>
             being used to generate the web interface that lets you view the
             repositories.
-            The <filename>gitlite</filename> software identifies users
+            The <filename>gitolite</filename> software identifies users
             using <filename>ssh</filename> keys and allows branch-based
             access controls to repositories that you can control as little
             or as much as necessary.
@@ -278,7 +285,7 @@
                 <listitem><para>Shared output that allows developer
                     testing and historical regression investigation
                     </para></listitem>
-                <listitem><para>Creates output that can be use for releases
+                <listitem><para>Creates output that can be used for releases
                     </para></listitem>
                 <listitem><para>Allows scheduling of builds so that resources
                     can be used efficiently.</para></listitem>
@@ -309,7 +316,7 @@
         <para>
             As with any development environment, it is important
             to document the policy used as well as any main project
-            guidelines so they are understoon by everyone.
+            guidelines so they are understood by everyone.
             It is also a good idea to have well structured
             commit messages, which are usually a part of a project's
             guidelines.
@@ -322,8 +329,7 @@
             project, it is worth sharing those with the community as soon
             as possible.
             Chances are if you have discovered the need for changes, someone
-            someone else in the community needs them also.
+            else in the community needs them also.
-            sooner than later.
         </para>
     </section>
 
@@ -331,7 +337,7 @@
         <title>Summary</title>
 
         <para>
-            This section summarizes thee key recommendations described in the
+            This section summarizes the key recommendations described in the
             previous sections:
             <itemizedlist>
                 <listitem><para>Use <link linkend='git'>Git</link>
@@ -617,7 +623,7 @@
                 A package is generally the compiled binaries produced from the recipe's sources.
                 You ‘bake’ something by running it through BitBake.</para>
                 <para>It is worth noting that the term "package" can, in general, have subtle
-                meanings.  For example, the packages refered to in the
+                meanings.  For example, the packages referred to in the
                 "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" section are
                 compiled binaries that when installed add functionality to your Linux
                 distribution.</para>