For software developers source code is more than just files on a disk - it's the result of hours of thought and work and must be protected. If you look at the number of software tools available to help developers track and store their source code, you'll see that code protection is a key part of any serious software development effort.

A software configuration management (SCM) tool is as important as a compiler or debugger, but as any experienced developer can tell you, getting your favorite tools to work together isn't always easy - especially when they're from different companies.

VisualAge for Java version 3.5 includes an External Version Control (EVC) tool that interacts with external SCM systems. Each project in VisualAge for Java can be associated with an SCM system (called "adding a project to version control") and a specific group of files in the SCM system's source code. Once you've added a project to version control, you can add classes to your SCM systems, check classes in and out of the system, and import the most recently checked-in version of a class from the SCM system into the Integrated Development Environment (IDE).

In Part 1 we discuss the following:

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

In Part 2 we'll continue with a discussion on path prefixes and refreshing your SCM files in the IDE.

Using the Team Server Instead of the EVC Tool
VisualAge for Java, Enterprise Edition, includes a team server (EMSRV) that enables you to share your code with other developers through a shared repository. One of the biggest decisions a development team needs to make is how to manage its source code: Should it use the team server, the EVC tool, or both?

The VisualAge for Java repository is inseparable from the IDE and is at the heart of most functions offered by the product. However, developers don't need to learn its SCM role if they're using another SCM tool. If you prefer a third-party SCM tool, you can use a local repository instead of the shared repository.

There are certain advantages to using only a local repository and the EVC tool:

• Less administration for the team (no team server required)
• No confusion about the location of the source code's most current version
• No confusion about source management processes
• More mobility since users can work disconnected from the network
• Less training for new developers since there's only one paradigm to learn

However, there are several reasons why developers may also wish to use a shared repository:

• Developers working on multiple teams may need to access both versioning systems.
• Code libraries may be more efficiently stored on a common server.
• Access to code previously stored in a repository might be necessary.
• Personal preference.
• Easy code-sharing capabilities.

There's no single right answer. The decision of which method to use depends on the characteristics and requirements of your development team.

The remainder of this article assumes that an external SCM tool will be used by the development team, and discusses how VisualAge for Java's EVC tooling bridges the gap.

Automatic Versioning of Your SCM Files
Every time you use the EVC tool in the VisualAge for Java IDE, the SCM files you're working with are automatically versioned, and new copies of those files are created in the VisualAge for Java repository. Also, before actions such as refreshing and checking out are performed, all the SCM files that are being modified are automatically versioned and named.

Versioned copies of your code can be very useful. If, for example, you refresh your project and accidentally replace a file you've changed with another unchanged version from your SCM system, you can simply replace the new version in the workspace with the older version from the repository using the Replace With > Another Edition menu item.

Although developers using the tool don't need to worry about the internal versioning that occurs, the tool itself relies on this information to track changes and determine courses of action during processing.

Merging Changes
Checking out source code before making changes is good programming practice when working with most SCM tools that are accessible via EVC. It lets teammates know you're modifying a file so they don't try to make simultaneous changes. Unfortunately, this rule is often broken. For example, a developer who needs to fix a bug while flying to a customer site doesn't typically have a connection to the LAN to check out the file before making changes. Whatever the reason, the bottom line is that conflicts will happen and merging will be necessary.

You can modify the source code for a project associated with an external SCM tool even if the code has not been checked out yet. The edits are allowed and you're reminded that you didn't check out the source yet. In addition, the status icon beside the filename shows a warning symbol. If it's necessary to check in the changes later, you can check out the file, resolve any conflicts, and then check in the code.

You can merge the code of an older version of a file with the code contained in a newer version. For example, you can import a file into the IDE without checking it out, then edit it and save your changes. If you then decide you want to check the file out from your SCM system but don't want to lose your changes, simply check out the file, compare the new and old versions, and merge any changes.

If you check out a file that someone else has changed, the difference is detected and you're asked how you want to proceed. You can either ignore the changes, leaving your source in the workspace, or you can ask to load the most recent version. This is where the automatic versioning comes in handy. Loading the new code will replace your changes, but they're safely versioned in the repository. Using the IDE's "Compare With" functionality, you can bring your modifications into the current source code and check in a properly merged file without accidentally deleting your co-worker's efforts.

Working with Class Groups and Resource Files
In the VisualAge for Java IDE you can elect to work with files on an individual or group basis. For example, if you wish to check in only a few files for a project, select those files and check them individually into your SCM system. If, however, you wish to check in all the files contained in a particular project or package, select the project or package and check in all the contained interfaces and classes at the same time.

However, any resource files associated with the selected project or package won't be checked in. Since resource files are not actually contained in projects or packages (they're only associated with them), any SCM actions you perform at a project or package level won't affect them. Instead, you must work with the files separately in the Resources page of the Workbench or Project browser.

Conclusion
Managing source code is an essential part of the development cycle, and there are many configuration management systems available to help you store and manage your code. However, because there are so many systems available, developers must not only decide which tool is best for them but also how that tool can work with their other development tools.

The EVC tool in VisualAge for Java version 3.5 enables you to manage your source code from within the IDE and work with many external configuration management systems. This allows you to enjoy the benefits of your SCM system while still taking advantage of VisualAge for Java's powerful development environment.

In Part 2 we'll continue this topic with an article on path prefixes and refreshing your SCM files in the IDE.