Author name

Mon, 11 Jun 2012

5 min read

Finding Lost Content with Rational Team Concert

Heather Fraser-Dubé, IBM Corporation
Build basis: Rational Team Concert 2.0, 3.0 and 4.0
Last updated: May 2012

I lost some changes that I made! How can I get them back?

Often we make changes to files and then decide either we want to revert back to an older version or we accidentally do something that overwrites the changes.

No need to panic. There are ways to get them back depending on what has happened. Your Development Environment (IDE) may provide some features to restore earlier versions of files and folders. Rational Team Concert (RTC) Source Control also provides the “Backup shed” feature.

Eclipse’s Local History

If your IDE is Eclipse, you may be familiar with its “Local History” feature. When you save and delete files and folders in Eclipse, previous versions are placed in the Local History. You can then compare to and restore the early versions.

When RTC Source Control manipulates the files and folders in your Eclipse workspace during Load, Accept, Suspend, Resume, Discard, Undo, etc., it also requests that earlier versions be placed in your Local History when it overwrites or deletes files and folders.

The life span and size of Local History is configured via the preferences.

To compare to an early version, select the file of interest in the Package Explorer. From the context menu choose Compare With > Local History. This will bring up a dialog from which you can choose the version to against.

To restore a file back to a previous version, select the file of interest in the Package Explorer. From the context menu choose the Restore from Local History menu option.

To restore deleted files/folders from Local History, select the project or folder that used to contain the deleted files/folders in the Package Explorer. From the context menu choose the Restore from Local History menu option.

RTC Source Control’s Backup shed

What’s a shed? A slight structure built for storage.

RTC Source Control’s Backup shed is a place on disk. An area away from your code where copies of files and folders can be stored. Backup copies of files and folders are placed in the shed when you perform Source Control actions such as Load, Accept, Suspend, Resume, Discard, and Undo. If enabled it is used when Eclipse’s Local History can’t be used. Basically when the files and folders being manipulated are not within an open Eclipse project, the Backup shed can capture the earlier versions. In order to be efficient, only the items that are locally changed are put in the shed. Unchanged items that get overwritten can always be recovered from your workspace’s history.

If you are using the Command Line Interface (CLI), the Backup shed is by default enabled for all commands (except Load in versions prior to RTC 4.0).

If you are using RTC’s client for Visual Studio, the Backup shed is by default enabled.

If you are using Eclipse as your IDE, the Backup shed is by default not enabled. You need to enable it via your preferences. You would want to enable the Backup shed when:

You load workspaces where all or part of the directory structure is outside of the Eclipse workspace.
You make local changes and close the projects prior to loading, accepting, etc.

By default, the maximum file size for backup consideration is 1MB. The life span is 7 days. This is the minimum time frame that a directory will be in the Backup shed. The shed is only cleaned up when new things are put in it.

If you are making changes to files outside of Eclipse, you may also want to consider enabling External Resource Changes as well. If you are running on Windows and RTC 4.0, you may want to turn on auto detection of changes.

The shed is located under the root of your Sandbox in the directory .jazzShed. Within this directory will be other directories with a name that reflects a timestamp. The timestamp is the time you performed an action and the directory contains the backup copies of the files and folders within it. The folder structure is preserved so you may need to navigate within to find your files and folders.

As an example. Suppose you have the JUnit example loaded into a sandbox at C:/MySandbox. Looking at the figure below containing an explorer view of the directory you can see the backup copy of the AboutDialog.java file. The Backup shed is the .jazzShed directory under the sandbox root. Within that is the directory b09-06-16 09.15.06.281, which means on June 16th, 2009 at 9:15am an operation performed resulted in some files being preserved. Under the backup directory is the backup copy of the AboutDialog.java file.

Check-in History (New in RTC 4.0)

This is essentially the history of a file within a change set.

Each time you check-in a file into a change set, the content is stored in the repository. Normally you see only the final version of a file within the change set. But sometimes you want to go back and see what the intermediate versions of the file were. Check-in History is an expansion of the changes made to the file each time it was checked into a change set.

To view the Check-in history of a particular file, show the history of the file. In the History view, toggle on “Show Check-in History”. Select a change set in the history of the file. The bottom pane will show the check-in history of the file within the change set. There is a merge graph that shows you deletions, additions, merges as well as regular modifications. When merges occur, you can even see the proposed copy that was merged in. You can view a particular version by opening the remote file. You can also compare versions and load the contents (to restore your local copy to that file).

As an example. Suppose you have the JUnit example loaded. Looking at the history of Vector.java you can see that a merge occurred (in the change set associated with work item 6223). Suppose you want to see what the contents of the file were prior to the merge. What you could do is look at the check-in history for Vector.java in the selected change set.

In the Check-in History, you can see every time the file was checked in, as well as the version of the file that was proposed during the merge.

In the Check-in History, you can see what Vector.java looked like before it was first checked in (Initial), after the first check-in (Modified), the version of that was proposed prior to the conflict being resolved and what the file looked like when it was last checked in right after the merge (Final – Modified). You can select any one of the versions in the check-in history and choose actions to load, open, even compare the selected version. Just another reason why you should check-in your changes regularly.

Putting it into practice

Below are some example scenarios along with steps you can perform to restore files.

I changed a file or deleted it and want to go back to what I had. My changes have not been checked in. They are under the unresolved folder in the Pending Changes view.

Undo your pending local change. This will go back to the last checked in state.
If you are using Eclipse, you can also recover the file from Local History.

I changed a file and checked it in. I made some more changes or deleted it.

Undo your pending local change. This will go back to the last checked in state.
If you are using Eclipse, you can also recover the file from Local History

I changed a file. Then made some more changes or deleted it and want to go back to the earlier (unchecked in) version.

You need to see what features your IDE has to help you recover. If you are using Eclipse as your IDE, you can use Eclipse’s Local History feature to recover the file.

I changed a file. Checked it in. I made some more changes or deleted it. I checked in those changes as well. I now want to go back to one of the earlier versions of the file that was checked in.

Use Check-in History to locate and restore the contents desired.

Select the file of interest and show its history.
In the history view select the change set into which the changes were checked into.
From the Check-in history of the file, select the version desired and load it.

I accepted incoming changes that overwrote unchecked in changes. I reloaded a component overwriting unchecked in changes. I undid local changes and want to get back the local changes. You can see the pattern here; you performed a Source Control action that updated your sandbox.

For operations like Accept, Suspend, and Resume, Source Control will warn you about known unchecked-in local changes that could be lost if you proceed. If you continue with the operation without checking in the changes they may be overwritten. In the case of Load, Source Control takes care to warn the user about overwriting the changes. But sometimes our mouse response is faster than our minds. Nevertheless, you can retrieve your overwritten changes.

If you are using Eclipse, you can restore the files and folders from Local History. If some of the projects were closed, or the items were outside of the Eclipse workspace, then if you had the Backup shed enabled, look in the .jazzShed directory in the root directory of the sandbox(es) that contained the items.
If you are using RTC’s client for Visual Studio or Command Line Interface, look in the .jazzShed directory at the root of the sandbox(es) that contained the items.

I am using Eclipse as my IDE, but I have some files (i.e. word documents, spread sheets, etc.) that I use other tools than Eclipse to modify them. I forgot to refresh my Eclipse workspace after making changes and accepted a changeset that also modified the same file. My changes are gone!!

Because the Eclipse Workspace was not refreshed prior to the Accept (Suspend, Resume, etc.). Source Control was not able to detect that the Eclipse workspace had changed and thus was not able to warn you about checking them in. Consider turning on the “External Resource Changes” option on the same preference page as the Shed preference. This way, a refresh check will take place automatically. When working on files outside of Eclipse you should always refresh the Eclipse folder afterwards.
you can restore the files and folders from Local History. If some of the projects were closed, or the items were outside of the Eclipse workspace, then if you had the Backup shed enabled, look in the .jazzShed directory in the root directory of the sandbox(es) that contained the items.

We deleted some files awhile ago and delivered the changes to our stream. I need to get some of those files back again

Find the change sets that deleted the files and load the file from the change set. See frequently asked questions for more details.

About the author

Heather Fraser-Dubé works for IBM and is a member of the RTC Source Control development team

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Feedback

Was this information helpful?

13 people rated this as helpful.