Gcube subversion repository
Contents
Introduction
"Subversion is an open source version control system. Founded in 2000 by CollabNet, Inc., the Subversion project and software have seen incredible success over the past decade. Subversion has enjoyed and continues to enjoy widespread adoption in both the open source arena and the corporate world. The project's original goal of being "a compelling replacement for CVS" (an older version control system with a similar model) was surpassed long ago — today Subversion stands on its own highly reputable name." (from Subversion homepage).
gCube software is configured in a Subversion repository reachable at following URLs:
- http://svn.research-infrastructures.eu/public/d4science/gcube/ publicly accessible in read-only mode
- http://svn.research-infrastructures.eu/d4science/gcube/ accessible only to authorized users in read and write mode
Repository's root is organized in five top-level directories:
- /misc: unused
- /tags: contains snapshots of gCube System releases
- /trunk: development version of gCube System
- /private: used by developers who want to develop new features in isolation without impact on trunk
- /branches: contains branches created during release cycles to release and integrate candidate versions of gCube components
Following sections provide, for each of aforementioned directories a description of the usage, internal structure and policies to follow to properly use them
Trunk (/trunk)
/trunk directory is used for development. Internal organization of trunk reflect as much as possible gCube project structure in ETICS: there is a directory for each subsystem that contains a directory for each component.
Developers commit new developments of their components in this directory. A policy that developers should always follows is to keep trunk in a consistent status for the most of time'. That means code in trunk should always compile. This is helpful for developers themselves that can use last version of all components to develop. Source code in /trunk is periodically built by a Continuous Integration Server to check the integration among development versions of gCube System's components.
Private Branches (/private)
Also known as Feature Branches, "It's a temporary branch created to work on a complex change without interfering with the stability of /trunk. Unlike release branches (which may need to be supported forever), feature branches are born, used for a while, merged back to the trunk, then ultimately deleted. They have a finite span of usefulness. [...] Most projects take a middle-of-the-road approach. They commonly insist that /trunk compile and pass regression tests at all times. A feature branch is only required when a change requires a large number of destabilizing commits." (from [Control with Subversion])
By convention, each developer creates a personal sub-directory of /private (the name should correspond to the developer's name) and work there. For instance, if developer John Doe wishes to create a private branch for component foo, it should be:
/private/john.doe/foo
Releases Snapshot (/tags)
Every time a new gCube version is released a tag for that version is created (that is foreseen as last step of Release Cycle Procedure). The tag will include all released components as they appear in ETICS gCube configuration. The aim is to have a complete, consistent snapshot of all released software for each gCube version.
Release Branches (/branches)
Until release gCube.1-7-4 /branches directory was used to create a branch of released gCube versions with maintenance purpose: if a maintenance release was needed, changes were committed on maintenance-branch instead of on trunk.
Starting from gCube.1-8-0 (may 2010) the release branching mechanism has been introduced and /branch directory started to contains branches created for components' release. The use of release branches assures a clear separation of trunk for development and branches for releases; i.e. minimizing the impact of ongoing development on code under release by also minimizing the need for feature/private branches and merges.
A release branch is created only when a new major or minor version of a component has to be released. When a patch releases (e.g. x.y.1, x.y.2, ...) is delivered no branch has to be created: changes will be committed on current release branch.
Naming Convention
Release branches name follows this convention:
/branches/<subsytemName>/<componentName>/<major>.<minor>
Some examples:
/branches/application/aquamapsservice/1.3 /branches/application/gpodwrapper/1.3 /branches/application-support-layer/application-support-layer-http/2.2 /branches/portlets-user/search-portlet/1.4
Relationship with ETICS configurations
Main advantage of having release branch is a clear separation from trunk used only for development and branches used for releasing and patching activities. That means all component's configuration in ETICS with the exception of .HEAD configurations will have the tag property pointing to a release branch path.
Further details on how to release components in ETICS please refer to Release Cycle Procedure
Figure below explains how ETICS configurations should points to SVN path
