Deleting Content From Source Control in Rational Team Concert

Table of Contents

  1. Introduction
    1. Prerequisites
    2. Scenario
  2. Deleting content with Eclipse
  3. Deleting content with the command line
  4. Encountering deleted content
    1. Eclipse
    2. Web UI
    3. Command line
  5. Conclusion

Introduction

Source control is useful for keeping track of all the versions of all your files. However, there are times when it should not keep a record of a particular version. For legal or security reasons, a particular version of a file should be removed so that users cannot view the content. Or, a large binary file in the repository is no longer needed and deleting it reduces database growth. This is when deleting content should be used to clean up inappropriate or obsolete data.

Deleting the content does not alter the history of the file. It will still show that a change was made when viewing the file history. Opening that version of the file will have no content to show. This is different than deleting a file or removing the content locally and checking-in the change because the inappropriate content is still preserved in previous versions.

Prerequisites

  • The user must be a JazzAdmin in order to delete content
  • Follow along using the JUnit Example project

Scenario

The following scenario uses the JUnit Example project. We will focus on Bill, Markus, and Jason. Bill is a developer that accidentally checked in inappropriate content. Markus is the administrator that will perform the clean up. Jason is another developer that encounters the deleted content after Markus cleans it up.

Bill has delivered a change set to his team’s stream that modified Math.java. The file contains content that was not cleared with the legal team. Bill did not realize this at the time and had started another change set building on top of the inappropriate content. He performs an undo on the change and delivers another change set to remove the inappropriate content. All versions of the file containing inappropriate content should be deleted so that it does not exist in source control at all. Bill notifies Markus to perform a cleanup.

Markus can delete the content with the Eclipse client or the command line. He should notify users that the file should not be edited. This prevents users from making changes on top of the inappropriate content. When Markus is finished cleaning up, users can resume editing the file.

Note: It is also possible to perform content delete in the Visual Studio or RTC Shell clients using the steps outlined below.

Jason receives the notification that he should not modify Math.java. When Markus tells everyone that it is clear to work on the file again, Jason can resume making his changes to Math.java.

Deleting content with Eclipse

Markus will have to delete all versions of Math.java containing the inappropriate content. Even though Bill delivered a change set that removed the inappropriate content, previous versions still contain it. First, Markus looks at the history view of the file. Since Bill delivered the change set, Markus can look in the stream for Math.java.

Using Show Repository Files on the JUnit component in the stream, Markus can find Math.java and display its history as shown in figure 1 below. He browses to Math.java and invokes Show History on it. This opens the History view where Markus can find the change set that introduced the inappropriate content.


Figure 1: Show history on Math.java

Markus also enables check-in history to view the past check-ins for the change set. Every time Bill checked in a change, it was saved in the history of the change set. Markus has to inspect every check-in by opening each file and delete the inappropriate content. Figure 2 below shows what the check-in history looks like. It shows the initial state before Bill made any changes and two check-ins. Markus should inspect the two check-ins and delete the versions with inappropriate content.


Figure 2: Viewing the check-in history of the most recent change set for Math.java

Note: It is important to delete these versions listed in the check-in history. Every check-in is preserved. If you check-in changes to a file several times, each of those changes is preserved so each version should be inspected for inappropriate content.

To delete the content, Markus selects the version in the change set and right-clicks to access the Delete Content action. Confirming the delete will permanently delete the content. All references to that version of the file will be deleted. Figure 3 below shows Markus deleting a version’s content.

Remember: You can only delete content as a JazzAdmin.


Figure 3: Deleting the final check-in of the change set

Since check-ins are preserved, Markus has to inspect the check-in history of any change sets building on top of Bill’s change set that introduced the inappropriate content and delete the content for those versions. Markus has to find the version where Bill checked in inappropriate content then performed an undo on the change. To find these change sets, he has to:

  1. Show change sets that have intermediate states modifying Math.java
  2. Show all change sets in the repository that modify Math.java

Then Markus must show change sets with intermediate states that modify Math.java. Figure 4 shows the preference to enable in the History preferences.


Figure 4: The History preference to show change sets with intermediate states that modify Math.java

Markus selects Show All in Repository when viewing Math.java‘s history. This will show all change sets in the repository that modify Math.java. These change sets may not be in the JUnit stream. It even shows change sets that were never delivered and were discarded from a workspace. Figure 5 shows the Show All in Repository button.


Figure 5: History view showing all change sets in the repository that modify Math.java

Markus will now be able to see all the change sets in the repository that have had a change checked in modifying Math.java. In figure 5, the most recent change set was not seen earlier but is now shown. This change set has a check-in history where Math.java was modified. Markus can inspect this and see that he has to delete the content for this version.

Deleted content will be marked in the check-in history with the date of the deletion and the user that deleted it. Figure 6 shows the updated check-in history of a change set after deleting the content.


Figure 6: The check-in history after deleting content

Deleting content with the command line

If Markus wanted to delete content with the command line, he would have to use these commands to find the change sets, list the checked-in versions of the change set, and delete the content.

  • lscm history
  • lscm list states
  • lscm delete state-content

Markus can find the change set by looking at the history of the component in the JUnit stream. First, he retrieves the alias for the JUnit stream:

lscm list stream --projectarea "JUnit Project" -r https://localhost:9443/jazz

Output:

(1418) "JUnit" JUnit Project

Markus now lists the history of the JUnit component in the JUnit stream using this command:

lscm history -w 1418 -c JUnit -r https://localhost:9443/jazz

Output:

(1407) ---$ Bill Cassavelli "bad content" 07-Jun-2012 11:56 AM  (1408) ---$ ADMIN "finish off javadoc" 06-Jun-2012 11:01 AM  (1409) ---$ ADMIN "Resolve conflict" 06-Jun-2012 11:01 AM  (1410) ---$ ADMIN "more doc" 06-Jun-2012 11:01 AM  (1411) ---$ ADMIN "Make unused public and protected methods private" 06-Jun-2012 11:01 AM  (1412) ---$ ADMIN "fixing bug in logo" 06-Jun-2012 11:01 AM  (1413) ---$ ADMIN "initial" 06-Jun-2012 11:01 AM  (1414) ---$ ADMIN "Initial for JUnit" 06-Jun-2012 11:01 AM

Markus can now look at the check-in history of Bill’s change set:

lscm list states 1407 -r https://localhost:9443/jazz

Output:

(1419) /<unresolved>/Math.java  (1420) Initial 07-Jun-2012 11:56 AM  (1425) Modified 07-Jun-2012 11:55 AM  (1426) Final - Modified [Content deleted by markus on 13-Jun-2012 02:06 PM] 07-Jun-2012 11:55 AM

Markus may load each version in the change set to inspect it for inappropriate content. Then Markus will delete the content of each version. In the example below, Markus deletes the other version from the change set we saw in the Eclipse client.

lscm delete state-content 1419 1425 -r https://localhost:9443/jazz

After each state is deleted, it can be confirmed by looking at the check-in history for the change set.

Output:

(1419) /<unresolved>/Math.java  (1420) Initial 07-Jun-2012 11:56 AM  (1425) Modified [Content deleted by markus on 13-Jun-2012 01:42 PM] 07-Jun-2012 11:55 AM  (1426) Final - Modified [Content deleted by markus on 13-Jun-2012 02:06 PM] 07-Jun-2012 11:55 AM

Encountering deleted content

When Markus is finished cleaning up the inappropriate content, Bill can resume working. If administrators did not cleanup Bill’s loaded content, he should delete Math.java. There are a few places where Bill may encounter deleted content. It is possible to continue working and there may be warnings that Bill should double-check that he is not reintroducing inappropriate content.

Deleted content may be encountered in these situations:

  1. Checking in a change when the previous version’s content was deleted.
  2. Performing an operation that puts the configuration in a state where a file has no content.

Eclipse

Bill continues working and checks in a new version of Math.java over the previous version that had its content deleted. There is a warning that the current version being checked in might have inappropriate content. Figure 7 shows the message when this happens. Bill should review the content before checking in to avoid reintroducing inappropriate content.


Figure 7: Warning when checking in a change on deleted content

Jason’s workspace is behind on the latest changes from the stream. He accepts Bill’s earlier change set that had inappropriate content. Since the content is deleted, he will be warned that the file’s content is deleted and a placeholder file will be created. Jason can load a previous version and continue working to ensure he does not reintroduce the inappropriate content.


Figure 8: Warning when accepting a change with deleted content

Web UI

If Jason goes to the web UI to view the file version with deleted content, he will see that the content has been deleted as shown in figure 9.


Figure 9: Viewing a file in the web UI that has deleted content

He can also view the check-in history to see which versions were deleted in the change set as is shown in figure 10 below. The comparison tells you which version in the change set was deleted that prevents the compare.


Figure 10: Viewing check-in history in the web UI that has deleted content

Jason can edit the file and deliver a clean version of the file. Since there is no content loaded, there is no worry of editing a bad version of the file.

Command Line

Jason loads his workpsace with the command line. The current configuration has Bill’s change set that had inappropriate content. When loading, there will be a message that Math.java has no content.

lscm load 1403 -r https://localhost:9443/jazz

Output:

The following items have their content deleted in the repository:   /JUnit Examples/src/com/ibm/team/junit/examples/Math.java   Successfully loaded items into the sandbox.

Jason can edit Math.java and replace the content with a previous version that did not have any inappropriate content. After Jason makes his changes, he has to check-in the changes with the -D option. This is for continuing the check-in operation even though the previous version has deleted content.

lscm checkin Math.java -D

Conclusion

In some organizations, security requires content removal. Others require the deletion of large, binary content to minimize database growth. Content deletion provides the necessary powers to purge content that should not be in the repository. A JazzAdmin will be able to browse through the versions of a file and delete the inappropriate content. After the cleanup, users can continue working and not be hindered by the missing content.


Feedback
Was this information helpful? Yes No 6 people rated this as helpful.