From 4d09a3c211159f097b7e68ac9e7d918a58daae8b Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Fri, 3 Feb 2012 12:33:05 -0600 Subject: 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 (From yocto-docs rev: 770c6799ea58df3d81df8f466f1bb9878532a995) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- .../dev-manual/dev-manual-bsp-appendix.xml | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) (limited to 'documentation/dev-manual') 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 @@ As mentioned, one way to get the Yocto Project files is to use Git to clone the - poky repository: + poky repository. + These commands create a local copy of the Git repository. + By default, the top-level directory of the repository is named poky: $ git clone git://git.yoctoproject.org/poky $ cd poky - 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 + poky-edison-6.0: $ tar xfj poky-edison-6.0.tar.bz2 - $ cd poky + $ cd poky-edison-6.0 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. + 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 + "Repositories, Tags, and Branches" section + for more discussion around these differneces. @@ -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, -- cgit v1.2.3-54-g00ecf