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>
This commit is contained in:
Scott Rifenbark 2012-02-03 12:33:05 -06:00 committed by Richard Purdie
parent deddea16d2
commit 4d09a3c211
1 changed files with 16 additions and 6 deletions

View File

@ -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,