Finding Lost Content with Rational Team Concert

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