Using a software configuration management (SCM) system is an integral part of any development project. Source code is your most valuable resource and must be protected. However, with the large number of products available from many different vendors, it's essential that you choose an SCM system that will work with your favorite development tools.

The External Version Control tool in VisualAge for Java, version 3.5, allows you to interact with several external SCM systems from within the integrated development environment (IDE). Once you've used the tool to associate a project in VisualAge for Java with a group of files in the SCM system, you can add and remove classes from the SCM system, as well as check classes in and out. In Part 1 of this article (JDJ, Vol. 6, issue 3) we discussed several aspects of this tool, including:

• Using the team server instead of the External Version Control tool
• Automatic versioning of your SCM files
• Merging changes
• Working with class groups and resource files

In Part 2 we expand on this topic by discussing two additional aspects of the External Version Control tool:

• Refreshing your SCM files in the IDE
• Manipulating path prefixes

Refreshing Your SCM Files in the IDE
To refresh a project that's been revised, version control will compare your workspace contents with the contents of the SCM server and allow you to synchronize your project in a customized way. Files will be refreshed only if their contents have changed since you created the project or since they were last refreshed. Many different types of inconsistencies are detected during a refresh operation, such as file deletions, new versions of files created by your teammates, and potential conflicts in which changes have occurred both inside the IDE and on the SCM server. You control how these inconsistencies are dealt with and choose the course of action in each case.

Depending on which SCM system you're working with, you may be able to refresh your files directly from your SCM system, or you may first have to ensure that your working directory is synchronized with the server, then refresh the files in the IDE. This process varies depending on the capabilities and versions of the particular SCM system you're using.

If you were prompted to import your SCM files from your working directory when you added your project to version control, you might need to extract the latest copies of your files from your SCM system and place them in your working directory before you try to refresh your project. Otherwise, you won't be able to refresh your project properly because your workspace will appear to be synchronized with the working directory.

It's usually preferable to have the refresh operation use the SCM server as its source of file information rather than the working directory. Unfortunately, this is not always possible, as it depends on the SCM system's capabilities. In most cases, the EVC tool will be able to detect the best way to refresh files and you won't typically need to adjust it.

Manipulating Path Prefixes
When you import Java source or compiled class files into the IDE, they're loaded into the appropriate package in the workspace. Resources, however, are handled differently. They're loaded into the associated project_resources/ directory, which is automatically included in the project's classpath at execution time. The directory structure within the project's resource directory will be preserved when importing resources. This becomes a problem if the original file in your SCM server has any extra subdirectory levels, as those levels will be mirrored and may leave your resources inaccessible to your programs without modifying the classpath. For example, consider a file in your SCM system that's stored as:

data/translatable/com/mystuff/labels.properties

When you import this file, you'll also import by default the data/translatable directories. When your code attempts to load the com.mystuff.labels resource bundle, it won't be able to find it.

To help avoid this situation, External Version Control lets you specify a path prefix that's removed during import and replaced during export. In the above example, setting the path prefix string to data/translatable will cause your resources to strip off these directories when importing. That means labels.properties will appear on disk as:

ide/project_resources/<project_name>/com/mystuff/labels.properties

This lets you use the files within the VisualAge for Java IDE without abandoning the organizational structure you've created on the SCM system.

The path prefix you specify in this window will be saved and listed in the Details page of the Version Control Properties window and in the Refresh Items page of the Refresh window. The prefix will automatically be removed from any files you import using the Refresh window when they're placed in the project_resources directory.

When you import a non-Java resource file into VisualAge for Java from your SCM system, you can elect to remove some or all of its path before it's copied into the project_resources subdirectory. Enter the name of the path prefix as it's displayed in the list of available files. For example, if you import a file that's stored on the SCM server as \Source\Resources\mypackage\mine. properties, and type \Source\Re- sources\ into this field, the file will be imported to the following directory (which will be created, if necessary): project_resources\projectname\mypackage.properties. If you're using the SCCI handler, you must also type the name of the drive on which the file is residing.

You might remove part of or the entire path prefix for the following reasons:

• To avoid creating extra, unnecessary subdirectories
• To control the directory structure of the resource files that will later be loaded from the SCM server

When you export a file to your SCM system from VisualAge for Java you can select to add a path prefix to it before it's copied into your SCM system. For example, if you're adding a file called mypackage/myfile.properties to the SCM server, and you enter resources into the prefix field, the file will be exported as:

resources/mypackage/myfile.properties

You may want to add a path prefix for the following reasons:

• To create a special subdirectory for resource files to reside in
• To control the directory structure of resource files that are added to the SCM server or loaded from it later

All .java and .class files are automatically imported directly into your project and placed into packages. The path prefix doesn't affect the names of these file types except when adding new types to the SCM server, in which case the path prefix will prepend the file name.

Conclusion
Source code control is an integral part of the code development cycle. There are numerous software configuration management tools available to help developers track and store their source code. This availability means that developers must determine not only which SCM tool is best for their use, but also how to make that tool work with other development products.

The External Version Control tool in VisualAge for Java, version 3.5, allows you to interact with several external software configuration management systems, enabling you to take advantage of VisualAge for Java's powerful development environment while enjoying the benefits provided by your SCM tool.