You are viewing outdated content for BUG. If you have a BUG Y.T. edition or 2.0 series device, please visit our updated wiki: http://wiki.buglabs.net
BUG SVN Info
From BUG Wiki
Contents |
Overview
The Bug Labs SVN repository is where all source code that we write or maintain for BUG goes. The URL is [| svn://svn.buglabs.net]. The repository is public for reading, but requires access to be granted by Bug Labs for checking in. This page describes the layout of the repository and the check in procedures for various projects.
SVN Layout
Bug SVN is broken into "products" at the highest level. Within each product lies the usual trunk/branches/tags layout.
bug
Here is where code that will end up on the BUG goes. This includes the Linux kernel, the JVM, and all the OSGi code that Bug Labs produced.
cte
Concierge Tools for Eclipse. This is a set of plugins for Eclipse that allow us easy development with OSGi bundles.
dragonfly
Dragonfly is the product name for the Bug SDK.
ote
OpenEmbedded Tools for Eclipse: some emerging code that is for use in making builds and packaging easier.
web
All Bug Lab's web code goes here, including the community site.
I have code to check in. Where does it go?
BUG code that fixes a current minor release
Code intented for the next minor BUG release, for example R1.4.3, would go into:
svn://svn.buglabs.net/bug/branches/R1.4/qa
When development is ready to issue a new RC to QA, svn://svn.buglabs.net/bug/branches/R1.4/qa is copied to svn://svn.buglabs.net/bug/tags/RCs/R1.4.x/RC1.4.x.y
BUG code for the next major release
Code intended for the next major BUG release goes into:
svn://svn.buglabs.net/bug/trunk
As of 4/1/09 our next major release is R1.5, so trunk == R1.5.
Experimental Code or Code for some unknown future release
For experiements and other code that may or may not make it into a release, a developer branch should be created. An example:
svn://svn.buglabs.net/bug/branches/felix_sandbox
Web code
Just about any web change should be made in trunk
svn://svn.buglabs.net/web/trunk
Please try to make sure all tests pass before committing code. If you plan to work over time and have things broken, then create a custom branch (see below).
If we're in a testing cycle and the change is a bug fix, the changes should be made in the testing branch.
svn://svn.buglabs.net/web/testing
When testing is over and the code is ready for release, a tag is made with the release number
svn://svn.buglabs.net/web/tags/releases/M.m.r
At that time, the testing branch is merged back into trunk and deleted.
Any major changes or experimental changes should be made in a custom branch
svn://svn.buglabs.net/web/branches/my_awesome_fixes
SDK code
Just about any SDK change should be made in trunk
svn://svn.buglabs.net/dragonfly/trunk
If you plan to work over time and have things broken, then create a custom branch (see below).
If we're in a testing cycle and the change is a bug fix, the changes should be made in the testing branch.
svn://svn.buglabs.net/dragonfly/testing
When testing is over and the code is ready for release, a tag is made with the release number
svn://svn.buglabs.net/dragonfly/tags/releases/M.m.r
At that time, the testing branch is merged back into trunk and deleted.
Any major changes or experimental changes should be made in a custom branch
svn://svn.buglabs.net/dragonfly/branches/my_awesome_fixes
I want to see the source for a given release
The BUG releases for R1.4 and above are stored at:
svn://svn.buglabs.net/bug/tags/releases/R1.4 or svn://svn.buglabs.net/bug/tags/releases/R1.4.x
BUG releases before R1.4 will be on our CVS server located at cvs.buglabs.net.
When things change
Designations such as "trunk" remain constant until:
- A new release is delivered to QA
- A new release is pushed to production
Changes for QA release
Major Release
In a major release the following transitions occur:
bug/trunk is copied to bug/branches/[release version]/qa [major release +1] becomes bug/trunk
Minor Release
In a minor release the following transitions occur:
bug/branches/[release version]/qa is copied to bug/tags/RCs/[release version]
Changes for production release
If a given RC is deemed production ready, the following change occurs:
bug/tags/RCs/[release version] is copied to bug/tags/releases/[release version]
Where is buildbot getting it's sources from?
Bug Labs buildbot is the build system we use to generate our products. Buildbot contains a number of builders for various products and versions. There are two primary build types.
Build Types
Incremental
Incremental builds checkout sources but leave existing sources and build artifacts in place. This results in a very fast build process but in some situations can cause the output to be inconsistent with the sources.
Full
Full builds start from a clean slate and build the entire system from scratch, including the cross compiler and other tools. This means it takes several hours, but the resultant binaries are consistent regardless of the build state or state of the tools.
Beyond the build types there are various places where buildbot extracts source from to build a given image or product.
trunk
This represents the next major release.
qa
This represents the next minor release.
repo
This represents the build slave for a major release, the ipks of which will arrive at http://repo.buglabs.net. The repo at this address will never have RC packages, so anipkg update; ipkg upgrade; ipkg install task-bugshould bring your bug memory card up to the current major release.
