Improved out of sync project handling for Jazz SCM
In this article we present the improved handling of out of sync projects found in Rational Team Concert 6.0.1. This improved workflow will preserve local changes when resynchronizing projects. First, this article will describe some common situations that can lead to an out of sync project. The article will go on to describe the reload process including the resolution of potential conflicts.
Video
Watch this video for an explanation of what it means for a project to be out of sync, how it can happen, and how the new features in RTC 6.0.1 make resynchronizing projects quicker, easier and more streamlined.
Introduction
In Jazz SCM, a user’s files and directories are organized in a repository workspace on the server. To work with these files a user will load the repository workspace into a local sandbox. In the Eclipse client the local sandbox is typically an Eclipse project. In the command line client, the local sandbox is a directory with special meta-data automatically stored at its root.
During normal operation, Jazz SCM will keep the state of the local sandbox and the remote repository workspace in sync as files are modified, accepted and checked-in. However, in certain rare instances, the local sandbox and remote repository workspace can become out of sync. When this happens, the sandbox and repository workspace must be resynchronized before normal SCM operations, such as check-in or accept, can be performed.
Typical causes of out of sync projects include:- Network connectivity problems during SCM operations
- Client or workstation failures during SCM operations
- Manipulating the same repository workspace in two or more separate local sandboxes
Identifying an out of sync project
RTC will tell you when a project is out of sync. The Eclipse client, Visual Studio client and the Command Line Client (CLI) will warn you if a project is out of sync whenever an SCM operation is attempted.
Eclipse client
Command line interface (CLI)
In Eclipse and Visual Studio a reminder will remain in the Pending Changes view until the issue is resolved.
Reloading an out of sync project
To get a project back in sync you must reload the project. The easiest way to do this is by clicking the “reload these projects” link in the Pending Changes view to open the load wizard.
By default, local changes will be preserved during the reload. In the rare case that you want to discard all your local changes, you can you select the “Overwrite local changes” option option on the second page of the load wizard.
Local conflicts
In most cases, the reload operation will finish without requiring any additional intervention. Local changes will be preserved and remote changes will be loaded. Even if a text file has changed locally and remotely, non conflicting changes will be merged automatically. Preserved local changes will remain in the Pending Changes view as unresolved changes waiting for check-in or further modification.
There are certain cases where the local file and remote file have changed in ways that can not be automatically merged. These cases will result in local conflicts.
Some situations that can result in local conflicts are:
- Overlapping regions of a text file are modified locally and remotely
- Binary or unknown file types are modified locally and remotely
- Structural changes occur both locally and remotely causing collisions, such as rename or move.
Resolving local conflicts
The cases above will result in local conflicts. The handling of local conflicts is very similar to the handling of remote, or repository workspace conflicts, which occur when the the changes in one or more accepted change sets conflict with the changes in change sets that already exist in the workspace. Just like workspace conflicts, local conflict are displayed in the Pending Changes view along with the related local changes that caused the conflict.
Local changes are resolved using the same four actions used to resolve repository workspace conflicts. They are:
- Resolve with mine
- Resolve with proposed
- Resolve as merged
- Auto-resolve
These actions are available from the context menu in the Pending Changes view when one or more conflicts are selected. You can also use these context menu actions on a parent folder to apply the same action to all the conflicts in the selected folder. If the folder contains both local and workspace conflicts you will be asked which type of conflict you wish to apply the action to.
The auto-resolve action is a special case to be used on files with unknown type. Some users have workflows where files have text content, but their type is unknown to the SCM system. In this case, invoking the auto-resolve context menu on the conflicts will attempt to apply a text merge to the local conflict.
Visual Studio client and Command Line Interface
Although this article used screenshots and descriptions of the Eclipse client, the improved out of sync workflow is also part of the Visual Studio client and the Command Line Interface (CLI).
In Visual Studio, the load wizard, Pending Changes view and context menus will appear very similar to the Eclipse client.
In the CLI, information is shown in the command output as various operations are performed when a project is out of sync. Pre-existing CLI commands have additional arguments to perform loads and conflict resolution in the presence of out of sync projects. Use the CLI help command to determine which arguments to use.
About the author
Dean Roberts is a member of the Jazz SCM development team and was a member of the feature team for improved out of sync handling.
© Copyright 2015 IBM Corporation
Yes