Development Process with VisualAge and CVS using vaj2cvs: A Case Study

Note: This article represents the views of a user of vaj2cvs, and is presented here by permission of the author, Peter Gassmann.

11.02.2000    peter.gassmann@acm.org

This document describes the development process when using the VisualAge to CVS bridge (vaj2cvs, developed by Kevin J. Grittner) in VisualAge for Java. The process is based on the following assumptions :

The above assumptions are described in more detail in the eXtreme Programming (XP) methodology.

The mentioned batch-files are simple shell-scripts which use a command-line version of CVS to commit and update non-java files. This is necessary because VisualAge (and the CVS Bridge) do not provide functionality to fully integrate non-java files.

Overall process

1. Start of work (morning)
2. Work (all day)
3. Integration (evening)

Start of work (morning)

1. Start VisualAge
2. Do a CVS-checkout on all needed projects
3. If anything has been changed (look at the CVS output), create a version in VisualAge ("after update"), to be able to throw away your changes, or to find out what you have changed during the day.
4. Invoke the batch-file "update properties from CVS" to update the non-java files
5. Run AllAllTests (system test) -> must be running at 100%. If not, a prerequisite is not met. Get in contact with the other team members. It might be necessary to install a new database or something like that.
6. Start working

Work (all day)

Creating a new class :

1. Add the class to VisualAge
2. Invoke CVS-add on the new class immediately, but do not invoke CVS-commit !!! This way the class will be added when you do a commit of the complete project (or on individual classes) during integration.
3. Continue working on that class

If you forget to add a new class in CVS, it will be recognized by CVS during a checkout. A class which only exists locally will be marked with a questionmark ('?') at the beginning of the respective line in the CVS output.

Deleting a class

1. Delete the class using CVS-remove, but do not invoke CVS-commit !!! This way the class will be removed in CVS when you do a commit of the complete project (or on individual classes) during integration.

Renaming a class

1. Copy the class using VisualAge Reorganize -> Copy. Do not use rename, because then you can't remove the old class directly from CVS !
2. Invoke CVS-add on the copy of the class (the new class)
3. Delete the old class à see deleting a class

Integration (evening)

The integration process should not be performed by different people at the same time, to avoid conflicts ! Make sure that no one else is integrating at the same time as you are !

1. Run all tests (AllAllTests). They should run at 100%.
2. Create a version of the project in VisualAge ("before integration")
3. Invoke CVS-checkout on the project, this way you get all changes others have made in the repository since your start of work. Vaj2cvs will merge all changes automatically, where possible. I've you've forgotten to add a new class during the day, you will see the class on top of the list generated by vaj2cvs, marked with a '?' at the beginning of the line.
4. CVS-update might report a conflict on a class. This happens when the same line of code has been changed locally and by somebody else. Vaj2cvs will popup a dialog, where you must select the code you want to use. If you don't select the code you want to use, the tool might fail, and the update will not be correct ! However, you might just comment out the block of code in question (marked by >>>>> and <<<<<), and then change it after having finished the update.

Attention : After having selected the code (or commented out) after the conflict, vaj2cvs will mark the class as a CVS version. As a consequence, commit won't be possible. But the class has not been changed in CVS ! Edit the class proforma (just add a blank somewhere and save). This way you can invoke CVS-commit afterwards and the tool will send the changed version containing the conflict fix to the CVS repository.
5. If you want to find out what has changed, just invoke VisualAge -> Compare with and select the version you created ("before integration"). Now you can see which classes have changed how during the day.
6. Run the update_m2_props.bat batch-file to update the configuration-files as well. The newest version will be needed in the tests.
7. Run all tests. Fix'em until they run at 100%. If you have commented out a block because of a CVS conflict, now you need to fix that as well.
8. Invoke CVS-commit on all classes with the Version-information "before integration", these classes need to be committed anyhow.
9. Invoke CVS-commit on all classes with no Version-information (those with a timestamp).
10. Alternatively to step 6 and 7, you could also invoke CVS-commit on the project. But this way you wont be able to add individual comments to each changed class.
11. Check again if all classes have been committed, eg. no class has a version of "before integration" or no version (just a timestamp).
12. Create another VisualAge version "after integration". This version enables you to find out what has changed since your last integration after the update in the morning.
13. Invoke the batch-file "commit properties to CVS" to commit changed non-java files

A bug in VisualAge

There is a bug in VisualAge for Java (version 2.x, Version 3.0) regarding recompilation of constants. Suppose you have the following code :

When you change the value of CONSTANT_A you would generally assume that the value of CONSTANT_B would reflect the change as well. However, VisualAge does in the above situation not recompile ClassB automatically if a change is made in ClassA. Therefore, CONSTANT_B does not have the value as expected. Now if you do a checkout from CVS of ClassA with a new value for CONSTANT_A, this will not be reflected in ClassB ! In this situation, you need to force a recompile in VisualAge. The easiest way to do this is to version the project, delete the project from the workspace and add it again. This could also be done just for packages or classes.

If this problem happens frequently in your project, write a test which exposes the problem and which displays an appropriate message. Run this test as the first test in AllAllTests, so it will be immediately clear what the problem is.