-
Notifications
You must be signed in to change notification settings - Fork 6
Crowbar tree branch structure
This page will attempt to describe the branch layout that we use and the dev tool attempts to maintain.
Things to note going in.
- Crowbar uses submodules to keep references to current barclamps for that branch of crowbar.
- Crowbar users branches to represent a collection of barclamps that should treated as a unit.
Releases are collections of branches in the crowbar repo that define a point in time branching of the code base. This release can then be modified and built with dev tool to provide maintenance and support.
The current releases for Crowbar are:
- development - The tip or Head of the crowbar tree
- active database models - rails3anddb feature branch (to be merged by 9/1/12)
- fledermaus - Crowbar 1.2 / OpenStack 1.2
- elefante - Crowbar 1.3 / Cloudera Hadoop 1.6
- fred - Crowbar 1.4 / Cloudera Hadoop 1.7 / OpenStack 1.3
- essex-hack - Deprecated release holding the fred release while we were working on elefante on development.
With in a release, there are a set of branches. These branches define an inheriting hierarchy to all for shared code across the solutions. The branches are:
- master - Top of hierarchy. Contains common barclamp references and code for all solutions.
- openstack-os-build - The OpenStack Open Source Solution (master is merged into this by dev tool)
- cloudera-os-build - The Cloudera Hadoop Open Source Solution (master is merged into this by dev tool)
- hadoop-os-build - The Hadoop Open Source Solution (master is merged into this by dev tool). Mostly defunct.
These branches are seen in github as simple branches. The naming convention allows dev tool and developers to identify the release from the branch. The branches that match the table are for the development release. The other release follow this naming convention:
- release/release name/branch name Where:
- release name is the name of the release (other than development)
- branch name is the name of the branch from the branch list above. For example, release/fred/master is the master branch in the fred release. release/elefante/cloudera-os-build references the Cloudera Hadoop Solution of the Elefante release.
Barclamps are not as complex as the crowbar tree itself. All work done a barclamp is done in master or the release specific version of master. For example, the nagios barclamp has a master branch with corresponds with work done in the development release. It also has a release/fred/master branch that represent the specific code that deals with the Fred release. The dev tool will maintain and update these values as you go forward. There is a special branch called empty. This branch is used by the dev tool to allow for a checkout point for barclamps that aren't in a specific crowbar repo branch. For example, the nova barclamp is not in master or cloudera-os-build branches. Dev tool will set the nova barclamp branch to empty to indicate that while a branch uses the nova barclamp, the current branch of this release does not.
Features are similar to releases, but are intended to be a single branch of a release for feature development. Though they don't have to be restricted that way. The follow the same pattern as releases except **feature **is prepended to the branch name instead of release.