Here's a like describing various methodologies we will be using the CvsLikePractice because we are a very small development shop and LOW overhead is what we need. http://mercurial.selenic.com/wiki/WorkingPractices

The main repositories are on feynman under /space/hg/repositories

There is a subdirectory for 3 main code groups:

• clientCode
• tool
• samm

Under each there will be at least 2 actual repositories and over time more will develop. Understanding the meaning of “major”, “minor” and “patch” wrt our versioning is useful please read: http://feynman.whatiftechnologies.com/dokuwiki/doku.php?id=definition_of_version_numbers_x.y.z.

The repositiories for each code group include:

• A main branch - new functionality for “major” or “minor” level changes
• A minor branch for each released branch of the code - any bug fixes or changes which will be released as a “patch”

Each time we release a “minor” version a new minor branch repository will be added to the directory. Each time we release a “patch” version a tag will be added to the minor branch.

Using tool as an example under /space/hg/repositories/tool will be the following repositories:

• tool_main
• tool_3.2
• each time we do a secondary dot release there will be one more repository like tool_3.3 etc.

As a developer you will need your own repository cloned from either the main branch or the minor branch depending on what needs changing.

Code to create a clone

NEED TO FILL IN

You can then make changes and commit them to your local repository as many times as needed until the code is ready for prime time.

Here's how you commit to your local repository

NEED TO FILL IN

Testing should be done on your own repository. When ready your development branch needs to be synchronized and committed to the authority version on feynman. Here's how you commit code to the main repository.

NEED TO FILL IN

TOOL and SAMM have their own accounts on feynman and under these is the dev/src directory structure. The released code should be available there as well as the head of each branch. Code here should NEVER be changed directly. Taking tool as an example:

• All versions prior to 3.2 will remain as they were 3.1.1, 3.1.2…
• 3.2.0 - clone authority 3.2 repository at the initial release of 3.2 - NEVER synchronize after creation
• 3.2.1 - clone authority 3.2 repository at the tag 3.2.1 - NEVER synchronize after creation
• 3.2_dev - clone authority 3.2 repository - Synchronize (pull) whenever 3.2 repository is updated – may make this a nightly script to update and build for now is MANUAL
• main - a clone from the authority main repository - Update whenever main repository is updated – may make this a nightly script to update and build for now is MANUAL

How to syncronize to the “head” of an authority branch

NEED TO FILL IN

The Changing Code process described above should be used to change code and the dev directories will be updated from the authority repository when we release code or when the “head” of a branch is updated.