How to use CVS

From Globus

The Globus Project always has numerous concurrent development activities underway with respect to the Globus Toolkit code base. In order to keep our CVS repository in a useful state for members of the project (including open source developers outside our core team), we use CVS branches to isolate these concurrent development activities from each other. This document describes how we use CVS branches in the hope that this information will be helpful for those using our CVS tree.

Branches

A branch is a mechanism that CVS provides to isolate the changes being made by different development activities from each other. Each development activity can create a branch within the CVS repository, and subsequently commit their changes to the code using that branch. Other users of the repository will not see these changes unless they explicitly ask for the contents of that branch.

Unless a branch is specified when checking out code from the CVS repository, the code obtained will be from the CVS trunk. The trunk is the most recently-released code, plus any bug fixes that have been made since the last release.

Bug fixes are made by any member of the development team at any time, depending on the severity of the bug and the people it is affecting. Our goal is to make bug fixes available as quickly as possible to the user community regardless of planned development activities or upcoming software releases.

Bug fixes are almost always made on the CVS trunk, not in a branch. Thus, the trunk always has the most recent release plus any bug fixes. Most remote CVS users will get the trunk.

Checking out

See http://www.globus.org/toolkit/docs/development/remote-cvs.html

Commiting

Only Committers can make commits to the Globus CVS repository. If you are not a Committer, you can still contribute by making patches and filing bugs against Bugzilla.

Some best practices:

• Please make sure the patch is conforming to the Coding Guidelines
• Make sure that the branch you are commiting to is not frozen
• It is the Committer's responsability to make sure he/she does not break any of the branches
• After a couple of hours of your commint, you can use Tinderbox to check for build failures. However, this should _not_ be used as a substitute for testing patches prior to committing!

Module Structure

There are two competing conventions for how to create directory structures:

1) component/language/sub-component/build-location, and
2) component/sub-component/language/build-location

Java and C core (i.e. the wsrf module) uses wsrf/java/core/source (#1) whereas the service component modules have evolved to use #2. The source/ directories are used for the main source under that sub-component (i.e. the actual service code).

If you have tests or some other sub-component-related source code, this goes in a different build location directory (i.e. GRAM has source/ test/ setup/ and usage/ under ws-gram/service/java).

For schema and stubs, the convention for service components (i.e. core does it differently) is to have a common/ directory with three main subdirectories: compact/ schema/ and java/source. Compact/ contains the "GWSDL" (i.e. our proprietary WSDL + inheritence extensions to avoid having to manually copy other WSDL file content) files and schemas. This isn't distributed, but is used solely to generate the offical WSDL files in schema/. The files in schema/ are committed and distributed with releases. The stubs and auto-generated class files from the schemas should go in a language-specific source directory. For example, Java stubs should be built in java/source/ and c stubs should be built in c/source/.

Although the above description in general describes how things are organized, you will find deviations from these rules simply because there were no hard and fast rules when the modules were originally created.