Working Optimistically with Eclipse and CA Harvest Change Manager

Document ID : KB000055487
Last Modified Date : 14/02/2018
Show Technical Document Details

The CA Harvest Change Manager (CA Harvest) Plug-in for Eclipse offers a friendly change management interface seamlessly integrated with the Eclipse development environment. A useful feature is the ability to work optimistically, postponing the checkout of files from CA Harvest until after you are done making changes. This article explores the tools and techniques that make working optimistically simple using Eclipse and CA Harvest.

"The Optimist's Guide to CA Harvest"

Learn how to take best advantage of an optimistic development philosophy using CA Harvest Plug-in for Eclipse.

Types of Configuration Management

The CA Harvest Plug-in for Eclipse supports both the Optimistic (late binding) and Pessimistic (early binding) philosophies. You can choose to use one or the other, or a combination of the two.

The objective of working optimistically is to relieve the burden of constantly interacting with CA Harvest as files are modified. When working optimistically, you are free to experiment with changes to files, and are offered tools to synchronize changes with a CA Harvest repository if you decide to commit them at a later time.

To look at the differences between optimistic and pessimistic modes, let's examine a few of the pros and cons. Depending on your needs, or the current working environment, you may find that a hybrid of the two methods is preferable. However, for the sake of this article, we will explore the use of the Optimistic mode.

Why Work Optimistically (the Pros)?

Some of the reasons you may choose to work optimistically include...

  • You're exploring ideas and don't yet know what needs to be changed.

  • You're disconnected from a network and have no connectivity to a CA Harvest broker.

  • You like to be free of checkout delays while changing files.

  • You want to work quickly with Eclipse tools that modify large numbers of source files (such as Java refactoring).

Why Not to Work Optimistically (the Cons)?

Some of the reasons you may choose not to work optimistically include...

  • You want to reserve changes to certain files (i.e. "lock" them if using Update mode), to prevent other users from modifying them.

  • You prefer to be always connected to the CA Harvest server while you perform your work.

  • You need to monitor development activity, specifically, which developers are currently working on which files.

The table below summarizes the differences between Optimistic and Pessimistic operations in the CA Harvest Plug-in for Eclipse.

 Optimistic
(Late Binding)
Pessimistic
(Early Binding)
Check-outMake changes to files without interacting with CA Harvest. Must check-out, and reserve a version, before making changes to a file.
Check-inSynchronize local files with the CA Harvest repository to reconcile differences. This results in check-outs and check-ins. Check-in pre-reserved files.
MergeYou have two choices:

Check-out from the latest trunk version and perform the merge entirely within Eclipse.

Check-out from the actual trunk version which was modified (requires concurrent checkout mode), then perform merge later using the CA Harvest Concurrent Me rge process.
Branch versions are merged after check-in using CA Harvest Concurrent Merge process.

Using Offline Mode for Late Binding Support - An Example

Here are the recommended preference settings and steps, to accomplish the Optimistic (late binding) mode of operation.

Recommended Preference Settings

Modify the CA Harvest CM preference settings, by locating the menu under the following Eclipse menu: Window>Preferences>Team>AllFusion Harvest CM. Under "Offline Development" (as shown in Figure 1 below) check the boxes for "Make files read/write on disconnect" and "Make files read/write on unshare". These options will make the files in the workspace writeable and will make the process of modifying and testing much simpler.

Figure1

Figure 1 : CA Harvest Plug-in Offline Development Preferences

Recommended Steps

  • Add To Workspace

    Use the CA Harvest Repositories View to navigate to the desired CA Harvest project, state, and data view path. Right click on a CA Harvest folder and select "Add To Workspace" to add the selected CA Harvest folder and descendants to the Eclipse workspace. See Figure 2 below for the first page of the Add to Workspace wizard.

    Figure2

    Figure 2 : Options Page of the Add to Workspace Wizard

  • Disconnect from CA Harvest

    Go to the Eclipse main menu and select "CA Harvest>Disconnect All Projects". This will logically disconnect the workspace operations from CA Harvest. This means that files can be modified without having to interact with the CA Harvest server, and enables the user to be physically disconnected from CA Harvest (if necessary).

  • Modify source and Test

    After disconnecting from CA Harvest, you can then edit, refactor, and update files more efficiently because it is no longer necessary to wait for files to be transferred from the CA Harvest server. Synchronization information is maintained in the Eclipse workspace to automatically track which files are modified.

  • Reconnect to CA Harvest

    Go to the Eclipse main menu and select "CA Harvest>Reconnect All Projects". This will enable the use of operations that require interaction with the CA Harvest server.

  • Synchronize with CA Harvest

    Right-click on the Eclipse project or any of its sub-folders or files and select "Synchronize with CA Harvest". This will cause the selected folder and its descendants to be checked for modifications. The CA Harvest repository will also be queried for changes to the selected items. A synchronization view will then be displayed that shows outgoing changes, incoming changes and conflicts. Conflicts occur where a file has both incoming and outgoing changes.

    Figure3

    Figure 3 : CA Harvest Eclipse Plug-in Synchronization View

  • Analyze conflicts and merge with changes from CA Harvest

    The user may find that some files are indicated to have conflicts (a double-headed red arrow symbol Arrow). Double-clicking on the file in the synchronization view will cause a compare/merge editor to be opened. This editor will have multiple panes to show the local version of the file and the CA Harvest version of the file. The user then steps through the differences and determines how to best merge with the changes from the CA Harvest repository.

    Figure4

    Figure 4 : CA Harvest Eclipse Plug-in Synchronization View

  • Mark completed merges

    After a file that has conflicts has been updated to incorporate changes from the CA Harvest repository, the file should no longer be considered to be in conflict. The user can choose to mark the file as merged by right-clicking on the file in the synchronization view and selecting "Mark as Merged". This will cause the file to then appear to have only outgoing changes.

  • Disconnect from CA Harvest

    At this point, the user may choose to once again disconnect from CA Harvest to run further tests.

  • Test and update merged code

    This cycle of updating locally, merging with CA Harvest, and testing locally may continue as needed. This development cycle is shown graphically in the Figure 5 :

    Figure5

    Figure 5 : Optimistic Development Cycle

  • Release changes to CA Harvest

    Once the user is satisfied that his changes will work with the versions of the files in CA Harvest, he can then reconnect with CA Harvest and "Synchronize with CA Harvest". If no further conflicts occur, he can then "Release" his changes to CA Harvest.

    During the release operation, you may encounter a dialog informing you that a later version exists. An example of this dialog is shown in Figure 6 :

    Figure6

    Figure 6 : Later Version Exists

    This situation will occur if other users have created more recent trunk versions since you began making changes. You have two choices to resolve the situation:

  • Checkout from the Workspace Version. This is the recommended approach if you wish to maintain full history of the modified version in CA Harvest. If you follow this option, a branch of the original trunk version will be created and you must merge using a CA Harvest concurrent merge process.

  • Checkout from the Latest Version. If you follow this option, a branch of latest trunk version will be created and you must merge your changes within the Eclipse merge tool prior to releasing.

Benefits

The following lists just a few of the benefits of using the Optimistic mode of operation:

  • Efficiency

    The user can save a significant amount of time by not being forced to wait for frequent interactions with the CA Harvest server. Once the user completes his modifications, he can interact with CA Harvest in batches of activity which incorporate much less overhead.

  • Automatic tracking of changes

    The user does not have to manually track which files are being modified. The changes will be clearly shown in the synchronization view. The user can check each change before committing some or all of them to CA Harvest. In Optimistic mode the version is not reserved, so if you don't want your changes you don't have to delete the reserved version. With Pessimistic mode, you have to delete any reserved versions for files you decided not to change.

  • Continue work while disconnected

    The user can continue working while away from the office (e.g. on a plane, at home, and so forth), during server upgrades, or any other environment where the client/server connection is unavailable.

Conclusion

To expedite changes in today's development environment, being able to work offline and/or detached from a central server can be beneficial. Using the Optimistic mode of operation, you can work in your own environment, at your own pace.

As shown in this article, being able to develop and test "offline" allows greater flexibility for the developer. It reduces overhead in daily editing tasks, allows freedom from network connectivity, and enables developers to perform merges directly in the Eclipse environment. Developers can easily decide, after their own testing, which files to ultimately check into CA Harvest. Then only those changes are tracked via CA Harvest file versions, while unnecessary versions are avoided.

While checking out code early in the development process has advantages, it isn't always practical. Therefore, having another way to work, the optimistic approach, might be the answer for your organization. With the CA Harvest Plug-in for Eclipse, you can work in one, the other, or both modes of operation. The choice is up to you!