sysmo-bts
/
generic-poky
9
0
Fork 0
Code Pull Requests Releases Activity

documentation/dev-manual/dev-manual-bsp-appendix.xml: tags/branches edits 

Edits to the section describing how to set up the YP files before the
BSP example.  I am working with Joshua Lock on these to settle them
down.  The edits are trying to establish understanding between a
Git repository and a tarball... just what the user has a hold of
after getting the files by either method.

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

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-02 11:16:54 -06:00 committed by Richard Purdie
parent e71d0af563
commit 11c290c3cf
1 changed files with 18 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
documentation/dev-manual/dev-manual-bsp-appendix.xml
View File

@ -31,7 +31,7 @@
The following paragraphs describe both methods.
For additional information, see the bulleted item
"<link linkend='local-yp-release'>Yocto Project Release</link>".
</para>
</para>
<para>
As mentioned, one way to get the Yocto Project files is to use Git to clone the
@ -45,19 +45,26 @@
$ tar xfj poky-edison-6.0.tar.bz2
$ cd poky
</literallayout>
<note>If you're using the tarball method, you can ignore all the following steps that
<note><para>If you're using the tarball method, you can ignore all the following steps that
ask you to carry out Git operations.
You already have the results of those operations
in the form of the edison release tarballs.
Consequently, there is nothing left to do other than extract those tarballs into the
proper locations.</note>
proper locations.</para>
<para>Once you expand the released tarball, you have a snapshot of the Git repository
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>
</para>
<para>
Once you have the local <filename>poky</filename> Git repository set up,
With the local <filename>poky</filename> Git repository set up,
you have all the development branches available to you from which you can work.
However, you need to be sure that your local repository reflects the specific
snapshot of the release you are interested in.
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.
You can also see the tag names used to mark snapshots of stable releases or
@ -70,8 +77,8 @@
</literallayout>
For this example, we are going to use the Yocto Project 1.1 Release, which is code
named "edison".
To make sure we have a local area (branch in Git terms) on our machine that tracks
the snapshot of the 1.1 release, we can use the following commands:
To make sure we have a local area (branch in Git terms) on our machine that
reflects the 1.1 release, we can use the following commands:
<literallayout class='monospaced'>
$ cd ~/poky
$ git fetch --tags
@ -84,10 +91,10 @@
local repository.
The Git <filename>checkout</filename> command with the <filename>-b</filename> option
creates a local branch for you named <filename>edison</filename>.
Your local branch tracks the Yocto Project 1.1 released tarball marked with the
<filename>edison-6.0</filename> tag in the source repositories.
Your local branch begins in the same state as the Yocto Project 1.1 released tarball
marked with the <filename>edison-6.0</filename> tag in the source repositories.
</para>
</section>
</section>
<section id='choosing-a-base-bsp-app'>
<title>Choosing a Base BSP</title>