documentation/dev-manual/dev-manual-bsp-appendix.xml: Edits to examples

Updated the tarball and Git repo example in section where user
is getting the source files.  I was not using the default
Yocto Project Files top-level name for the tarball method.

Reported-by: Joshua.lock <joshua.lock@intel.com>
(From yocto-docs rev: 770c6799ea58df3d81df8f466f1bb9878532a995)

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

1 files changed, 16 insertions, 6 deletions

diff --git a/documentation/dev-manual/dev-manual-bsp-appendix.xml b/documentation/dev-manual/dev-manual-bsp-appendix.xml
index 8a5ad73f86..50522a213b 100644
--- a/documentation/dev-manual/dev-manual-bsp-appendix.xml
+++ b/documentation/dev-manual/dev-manual-bsp-appendix.xml
@@ -35,15 +35,20 @@
 
     <para>
         As mentioned, one way to get the Yocto Project files is to use Git to clone the 
-        <filename>poky</filename> repository:
+        <filename>poky</filename> repository. 
+        These commands create a local copy of the Git repository.
+        By default, the top-level directory of the repository is named <filename>poky</filename>:
         <literallayout class='monospaced'>
      $ git clone git://git.yoctoproject.org/poky
      $ cd poky
         </literallayout> 
-        Alternatively, you can start with the downloaded Poky "edison" tarball:
+        Alternatively, you can start with the downloaded Poky "edison" tarball.
+        These commands unpack the tarball into a Yocto Project File directory structure.
+        By default, the top-level directory of the file structure is named
+        <filename>poky-edison-6.0</filename>:
         <literallayout class='monospaced'>
      $ tar xfj poky-edison-6.0.tar.bz2
-     $ cd poky
+     $ cd poky-edison-6.0
         </literallayout> 
         <note><para>If you're using the tarball method, you can ignore all the following steps that
         ask you to carry out Git operations.  
@@ -56,8 +61,12 @@
         that represents a specific release.
         Fundamentally, this is different than having a local copy of the Yocto Project 
         Git repository.  
-        Given the tarball method, changes you make are building on top of a release, while
-        you are tracking development when you use the Git repository method.</para></note>
+        Given the tarball method, changes you make are building on top of a release.
+        With the Git repository method you have the ability to track development
+        and keep changes in revision control.
+        See the 
+        "<link linkend='repositories-tags-and-branches'>Repositories, Tags, and Branches</link>" section
+        for more discussion around these differneces.</para></note>
     </para>
 
     <para>
@@ -66,7 +75,8 @@
         Next, you need to be sure that your local repository reflects the exact
         release in which you are interested.
         From inside the repository you can see the development branches that represent
-        areas of development that have diverged from the main (master) branch.  
+        areas of development that have diverged from the main (master) branch
+        at some point, such as a branch to track a maintenance release's development.  
         You can also see the tag names used to mark snapshots of stable releases or 
         points in the repository.
         Use the following commands to list out the branches and the tags in the repository,