Version Control Process
You can browse CVS here.
CVS Installation The instructions to install CVS can be found here.
CVS Daily Process To take advantage of the version control system, commits to CVS should be done when:
- Test Driven Development Unit Tests are created
- Defined Unit Tests are passing
The three step process to 'commit' code:
- 'Update' your local CVS environment
- Re-run unit tests to ensure they still work after update
- 'Commit' and comment changes to CVS repository
Tags and Branching in CVS There are two types of tag. Regular tags give a name to the files in a module at a certain point of time. Branch tags are used to name an entire branch in the repository.
Create A Tag Tags should be created for Official Code Drops using the following tag naming convention: (REL_YearSheculedforRelease_MajorReleaseNumberofTheScheduledYear_MinorReleaseNumber_SubMinorReleaseNumber) examples: REL_2005_1_10_0, REL_2005_1_11_3, REL_2005_2_1_0, REL_2006_1_5_0
Since each file in CVS is automatically updated with a version number, it is very difficult to checkout code using just the files version number. Tags allow the developer to checkout a version of the code based on a certain tag.
Create A Branch Branches should be used sparingly. Branches for the project will be generated for only a few reasons:
- Release moved to Production
- Major Refactoring of the entire client and/or server environment(s)
- Major development experimentation
Branches should be created using the following branch naming convention: (RB_YearSheculedforRelease_MajorReleaseNumberofTheScheduledYear_MinorReleaseNumber_SubMinorReleaseNumber) examples: RB_2005_1_10_0, RB_2005_1_11_3, RB_2005_2_1_0, RB_2006_1_5_0
NOTE: Not all taged releases require its own branch. Only those releases that will be put into production should have its own branch.
Generating A Release Branch The following are the steps to create a release, provide bug fixes to that release and merge those bug fixes back into the main code stream (main branch of code that developers utilize).
The example utilizes the cvs dos-prompt commands to simplify the process. The same functions can be accomplished using WinCVS? or the CVS perspective in WSAD.
Resolving Merge conflicts When a merge conflict occurs or you just want to see what is the difference between two versions of the same source file a code diff tool is required. This is where WinMerge is utilized. The following steps are used inside WinCVS:
- Select the file you want to compare
- Right-click select 'Diff selection' or use hot-key 'Ctrl+d'
- On the Diff Setting Tab|Diff Compare Options :: select the appropriate 'Compare Type'
- On the Diff Setting Tab|Command Line Diff Options :: click the 'Use the external diff' (This will allow CVS to run WinMerge)
|
|