General Questions

Making Changes

Discarding Changes

Finding Changes

Troubleshooting

What's a resource?

Resource is a generic term we often use to describe either a file or a folder.

It sounds expensive to have streams and repository workspaces keep copies of all files?

In some documents about Jazz Source Control it sounds like each repository workspace and stream has a complete copy of all the files and folders in the repository. This is an oversimplification. Under the covers histories are shared and when creating a repository workspace from a stream, only the pointer to the stream's history needs to be referenced. Then as new change sets are created in the repository workspace they are appended to a new history owned by the workspace.

I'm used to CVS/SVN, so I understand checkout and update, but what do load, unload, accept, and deliver mean?

Both CVS and Subversion use the terms checkout, commit, and update. In CVS/SVN:
  • checkout downloads the content of the branch to your local computer,
  • commit uploads your changes to the branch and makes them available for others, and
  • update downloads the latest changes from the branch to your local computer.

In Jazz, a load is equivalent to checkout: it downloads the content of a repository workspace onto your local computer. When you want to remove the local workspace from your computer, you unload it. Unload is the same as deleting the SCM directories in CVS or Subversion.

A check-in in Jazz causes any changes in your local workspace to be uploaded to your repository workspace. The changes are only added to your repository workspace, so the rest of your team won't know about them. Neither CVS nor Subversion have a similar operation.

A deliver adds the change sets in your repository workspace to a stream. The change sets are then available to the rest of your team. If you're used to CVS/SVN, then you can think of this as a commit.

An accept is very similar to a CVS/SVN update. It inserts the new change sets from the stream into your repository workspace and updates your local workspace. Note that if you accept changes into a repository workspace that isn't loaded, then the changes will only be added to the repository workspace. The next time you load the repository workspace, the changes will be available.

Checkout the Jazz Platform Quick Reference for more terminology explanations.

Making Changes

I modified a file. How do I deliver it to my team?

If you have modified file JUnit/src/junit/framework/Assert.java and want to make the change available to the rest of the team, follow these steps:

  1. Assert.java should be an unresolved change in the Pending Changes view.
  2. To open the Pending Changes view. (You can type Ctrl-3, "vpc", and Enter to show it)
  3. Expand the "Unresolved" folder of the component. The folder containing the file changed will be listed.  Expand it and there should be a change representing Assert.java.
If you want to immediately deliver this to your team, follow these steps:
  1. Select the outgoing change. Right-click and select "Check-in and Deliver...".
  2. In the Wizard, enter the comment you want on the change set.
  3. If there is no work item associated with the change click Finish, otherwise click "Next" and either pick an existing work item or create a new work item.
If you want to accumulate several changes before delivering to your team, follow these steps:
  1. Select the outgoing change.  Right-click and select "Check-in > New Change set".
  2. Expand the Outgoing folder to see your new change set.  Expand the change set to see your change.
  3. To add a comment to the change set; select the change set, right-click and select "Edit Comment".
  4. To associate a work item with the change set; select the change set, right-click and select "Associate Work Item..."
  5. Finish your other changes.  To check them in, select the changes, right-click and select "Check-in >" and pick your new change set.
  6. When your changes are complete, Select the change set, right-click and select "Deliver"

The change will be added to the stream you have configured to flow your changes to. Other developers will be able to accept the change from there.

How do I accept incoming changes from my team?

If you are working with other people, you will eventually see incoming change sets. They are shown under the "Incoming" node of the Pending Changes view.

  1. Open the Pending Changes view.
  2. Examine the incoming change sets inside the Incoming folder. Each change set contains a list of modified files, and work items.
  3. Right-click on the incoming folder and select "Accept." If you only want to accept one change set, right-click on that change and select "Accept."

The change will be added to your repository workspace. If you have the workspace loaded locally, then the changes will be applied to your local workspace as well.

Sometimes I have outgoing change sets that I didn't write. What's going on?

<원인>

If you have accepted a change set into your workspace, and the change set is then discarded from the stream, the change set will be shown as outgoing.

<"Incoming" 폴더와 "Outgoing" 폴더에 대한 설명>

The "Incoming" folder shows change sets that the stream has but your repository workspace does not have.  The "Outgoing" folder shows change sets that your repository has but the stream does not.

<이유 : Stream의 특정 component의 baseline이 "뒤로" 바뀐 경우>

What has happened is someone removed a change set from the stream by replacing the component in the stream with a baseline that doesn't contain the change set.

<해결책1>

To simply discard all the outgoing change sets; select the component, right-click and select "Replace With > Latest from <your stream>".  This will copy the streams configuration to your repository workspace and remove the unwanted change sets.

<해결책2>

If you have some change sets that you want to keep, just discard only the unwanted change sets.  Select the change sets that you didn't write, right-click them and select "Discard...".  If you can not discard the change sets because it would introduce a gap, it means that you have started to build on top of the changes that have now been removed from the stream.  You have a couple of options.  You can effectively remove the change set from the stream by reversing it.  The alternative option is to create a patch for your work, discard all the outgoing change sets by replacing with the latest from your stream, then apply the patch containing your work.

The Pending Changes view is verbose about these differences between the repository workspace and the stream. To avoid causing this problem for other users, when you want to remove a change set from a stream, use the reverse action.

How do I share a file that's ignored by default?

Jazz ignores two types of files by default: resources ending in .class, and everything contained in the bin directory of the project root.

If you want to share a .class file, you have to remove the *.class pattern from the global ignore list. To do so:

  1. Edit or create the the file .jazzignore in the root of your project. The file is a standard Java properties file.
  2. Add the line 
    core.global.ignore=
    to the .jazzignore file. If the line core.global.ignore already exists, remove the pattern *.class from it.
  3. Save the .jazzignore file.

This will cause files ending in .class to be checked-in to the repository workspace by default.

If you want to share the contents of your bin directory, then you have to remove the pattern bin from your root .jazzignore file.

  1. Select the directory bin in the project root.
  2. Right-click and select "Team > Remove from Ignore List".

This will share the contents of bin.

How do I deliver changes to an ignored resource?

If some resource, for example "junit_tests.launch",is ignored, but you want it to appear in a change set, follow these steps:

  1. Unignore the file (in the Navigator view, select the resource, right-click and select "Team > Remove from Ignore List").
  2. Open the Pending Changes view, and find "junit_tests.launch" in the Unresolved folder. It should co-exist with a change to the ".jazzignore" file.
  3. Check-in the change to "junit_tests.launch" with any other changes you want it to co-exist with.
  4. Deliver the change set(s).
  5. Select the ".jazzignore" file in the Unresolved folder.  Right-click and select "Undo".  By undoing the ".jazzignore" file change, "junit_tests.launch" will become ignored again.
If your ".jazzignore" file should accidentally get checked-in during the development of your changes, follow these steps:
  1. Move the ".jazzignore" change to a change set all by itself.  Select the change, right-click and select "Move > New Change set".
  2. Do not deliver this change set when you deliver your changes.
  3. Once your changes have been delivered; select the change set, right-click and select "Discard...".

Discarding Changes

I want to stop working on a change set and do something else. How do I get the change set out of my workspace?

Jazz allows you to temporarily remove a change set from your workspace by suspending it. At some point in the future, you can resume the change set and continue working on it. To suspend a change set;

  1. Open the Pending Changes view, and select the outgoing change set you want to suspend.
  2. Right-click on the change set and select "Suspend"

The change set will be removed from your "Outgoing" changes node, and put into the "Suspended" node associated with the component.

When you want to start working on the change again, you can resume it.  You can resume it into the same workspace as you suspended it from or in a different one of your workspaces.

  1. Open the Pending Changes view, expand the "Suspended" folder under your component and select the suspended change set you want to resume.
  2. Right-click on the change set and select "Resume"

The change set will return to your "Outgoing" changes node.

Note: A suspended change set can conflict with changes in your workspace. When that happens, you will be asked to resolve the changes after you resume.

Note: If you have open change sets modifying the same resources as an open change set being resumed, you will be told about an overlap.  Only 1 open change set can contain changes for a resource.  The resume will allow you to close the change set being resumed.  If you don't want to do that, you can suspend the change set(s) that overlap and then re-attempt the resume.

I want to permanently get rid of an outgoing change set in my workspace. How do I get rid of an undelivered change set?

Outgoing change sets can be discarded, which will remove the modifications from the workspace. If the change set is associated with a work item, then the change set can be re-accepted from that work item; otherwise, you can search for the change set.

  1. Open the Pending Changes view, and select that change set in the Outgoing folder.
  2. Right-click on the change send select "Discard."

How do I remove a change set from a stream?

To remove a change set from a stream you can create a new change set that reverses it. To reverse a change set, the changes made in the change set are first undone.  Then the reversing changes are checked into a change set that can be delivered to the stream.

  1. Open the History view on the component that contains the unwanted change set.
  2. Find the change set you want to reverse in the History view.
  3. Right-click on the change set and select "Reverse".  This will create a set of patches that can be applied to your local workspace to reverse the changes made by the change set.
  4. In the pending changes view, expand the "Pending patches" folder to see all the reversal changes.  You can examine them in detail by double clicking on them.
  5. When you are ready to apply the changes to your local workspace, select the "Reverse: " patch (or individual changes), right-click and select "Merge into Workspace".  This will merge the changes into your local workspace.
  6. If a file has changed significantly since change set being reversed, you may encounter conflicts in merging the changes.  In that case you will need to merge the changes in manually in the compare editor.  Double click on the file to open the compare editor.  Manually merge in the changes in the compare editor.  Once you have manually merged the changes, you can select the change within the "Pending Patch" folder, right-click and select "Remove from view".
  7. Check-in the changes in your local workspace into a new change set.  Ideally you will associate the new change set with the same work items as the change set being reversed and include the comment that the change set is a reversal.
  8. Deliver the change set containing the reversal to the stream.

You can also discard a change set from the stream by replacing the component's configuration with a baseline that does not contain the change set.  However, when a change set is discarded from a stream in this manner, it will appear as an outgoing change set for anyone who has already accepted it.  It will also cause problems for anyone who has since built on top of that change set.

  1. Open the History view on the component that contains the unwanted change set.
  2. Find the change set you want to remove in the History view.
  3. Right-click on the change set and select "Discard".  You will not be able to discard a change set that incorporated merges.  If there are other change sets that have built additional changes upon the resources changed in this change set, you will not be able to discard it due to gaps. In these situations, you will need to follow the steps above to create a reversal change set.
  4. In the Pending Changes view, the change set that was discarded will be shown as incoming from the stream again.
  5. Create a new baseline.  Select the component that has the change set to be discarded, right-click and select "New > Baseline".  You will be told that there are incoming change sets that will not included in the baseline, this is ok.  Ideally, you will provide information in the baseline label and/or description identifying that you are discarding a change set.
  6. Replace the stream's component configuration with the new baseline.  Select the component, right-click and select "Replace in <your stream>".  You will be asked to confirm you want to replace the contents in your stream.  Just before the replace takes place, a baseline of the stream's component will be created.  That baseline will contain the change set being discarded.  That baseline will be associated with the stream's component allowing you to later compare to it, or even replace the component in your workspace with it.

Finding Changes

I discarded a change set I was working on, but I really need it back again.  How can I find it?

If the change set you discarded was associated with a work item, you can get it back from the work item.  Open the work item and on the links tab in the links section, you will see the change sets associated with the work item.  Select your change set and from the context menu (right-click) select accept to accept it back into your workspace.  You could also just open it in the Change explorer by double clicking on it.
If the change set is not associated with a work item, you will need to search to find it.
  1. In the pending changes view, click on the triangle in the top right hand corner of the menu bar.
  2. From the drop-down menu choose "Search for Change sets...".
Pending changes drop-down menu
  1. This will present a dialog that allows you to specify details about the change set you want to search for.  You will want to fill in the component it was for, but not the workspace (because it doesn't belong to any workspace, it is discarded).  Also fill in Current User as the creator and if possible the time frame in which it was created.  This will help narrow down the results.
  2. The change sets found that meet the criteria will be shown in the Search view.
  3. Select your discarded change set, right-click and select "Accept" from the context menu.

We deleted a file awhile ago.  How do I restore it?

First you need to find the change set that deleted the file.  Reverse the change set and apply the addition of the file that was deleted.  Because Jazz keeps track of resources based on identity, once the file is restored, you can show the history of it and see the full history of it including the changes made to it prior to the deletion.  This is much better than trying to copy and paste the contents in a new file as that would not maintain the history.
  1. To find the change set, in the pending changes view, click on the triangle in the top right hand corner of the menu bar.
  2. From the drop-down menu choose "Search for Change sets...".
  3. In the dialog presented, provide as much detail as possible regarding the component, workspace and time frame in which the change set was created.  At the bottom of the dialog there is a section for searching for a change set with a particular type of change.  Search for the deletion change and specify the name of the file you are interested in.  For example if Markus was searching for the Logo.java file that had been deleted from the JUnit component of his workspace, he would fill in the following search criteria.
Change set search criteria
  1. The change sets found that meet the criteria will be shown in the Search view.
  2. Select the change set that deleted the file, right-click and select "Reverse" from the context menu.  This will create a set of patches for all the changes in that change set.
  3. In the pending changes view, expand the "Pending patches" folder to see all the reversal changes.  Find the file you want to restore.  It will be an addition patch.
  4. Select the addition, right-click and select "Merge into Workspace".  This will restore the file into your local workspace.
  5. Select the remaining changes in the "Pending patches" folder, right-click and select "Remove from view" to ignore the other changes that were in the change set.
  6. Check-in the restored file into a change set and deliver when ready.

I loaded/accepted changes and lost my unchecked in changes. How can I get them back?

Accept, suspend, resume and other operations that manipulate the files and folders within a loaded workspace on disk ask you if you want to check in your pending changes. It is always a good idea to do that. Sometimes you may not, or you may re-load your workspace resulting in un-checked in changes being removed. You can get them back though either from Eclipse's local history or from Source Control's backup shed. For full details see See Finding Lost Content.

How do I know if my change set is in a release? in a build?

Releases are usually considered important points in time and it is recommended that snapshots or baselines are created to capture the configuration at that point in time.  That way you can re-create the configuration later.  Sometimes separate streams are used to track changes for other releases.  Team builds will create a baseline for the configuration being built.  See the Multi-stream development tutorial for more details.
If you know what baseline, snapshot, or stream represents a release or the build baseline, you can determine if your change set is within that configuration.
  1. Select your change set.  The change set might be shown in the work item editor links, the history view, the change set search results pane or the change explorer.
  2. Right-click and select "Locate Change set..." from the context menu.
  3. In the dialog presented specify the search criteria for the baseline, snapshot or streams you want to search.  You may need to click Next to fully specify the criteria.
  4. Click Finish when all the search criteria has been provided.
  5. When the search is complete, you will be told if the change set was found.  If it was found, you will have the opportunity to see it in the history view.

Troubleshooting

My local workspace is out of sync with my repository workspace.  How did that happen?  What do I do?

Jazz can detect when changes have been made to a component in your repository workspace but have not been reflected in your local workspace.  Once it has been detected that things are out of sync, you will be given suggestions on how to reload your workspace to get back in sync.

How did it happen?

Typically things get out of sync when you perform an action that involves updating the configuration of a component in your repository workspace but before the local workspace is fully updated, the action is cancelled or fails unexpectedly.  Most actions involving changes or conflicts affect the component configuration (for example, accept, discard, suspend, resume, resolving conflicts, undoing checked in changes, etc.).  It can also happen if you are loading the workspace but prior to all the content being loaded it is cancelled or fails.  A less common case is when you have the same repository workspace loaded in multiple local workspaces and you perform actions that modify the configuration of the repostiory workspace via one of the local workspaces (the other local workspace will become out of sync).

What should you do?

  • If you don't have any unresolved changes awaiting check-in, it is simple.
You just need to load the projects that are out of sync.  The load is incremental and it will only load the resources that are missing.  When you perform an action that affects the configuration of a component it will first check if the local workspace is in sync for that component.  If not, you will be told the projects that are out of sync and prompted to reload them.  Once the reload is complete the original action will continue.  If you are unsure if other components are out of sync or not, you can re-load the entire workspace.  In the load wizard when you get to the page asking you to confirm the overwrite of existing projects, click on the "Select Out of Sync" button to select just the projects that are out of sync.  This will also help to reduce the load time.

  • If you have unchecked in changes...
Reload is only an option if you are willing to lose the changes (the files are going to be replaced with the version in the repository workspace).  If you don't want to lose the changes, you should cancel the current operation and get back in sync.  To preserve the changes you should create a patch.  Select the unchecked in changes, right-click and select "New > Patch".  Save the patch in a file.  Load the workspace.  In the load wizard when you get to the page asking you to confirm the overwrite of existing projects, click on the "Select Out of Sync" button to select just the projects that are out of sync.  The reload is incremental.  Once the Eclipse workspace is back in sync again (and no errors during the load).  You can then apply the patch, from the menu bar select "Project > Apply Patch".  Once you merge in the pending patch changes, you will be up to date and can proceed with the original operation.

I want to share a project but I got an error about the encoding not matching the contents.

Basically, there is a text file that Jazz attempted to read when checking in the project contents that it could not because the content does not adhere to the encoding rules.  The error message should provide you with the name of file that caused the problem.

Within Eclipse, you have a default encoding for text files.  To see what it is, from the toolbar select "Windows > Preferences... > General > Workspace".  If this is not the encoding for most of your text files, you should change it here.  When working within a team you should decide upon a common encoding that you and your team will use.  That encoding should also be available on the server (for annotate to work well).  You will need to communicate with the rest of your team what the encoding is.

Eclipse also allows you to override an individual file that has an encoding that is different from all the rest.  To do this, select the file in the package explorer (or navigator) view.  Right-click and select "Properties... > Resource" to open the properties browser.  You can now change the Text file encoding.  We have found that the "ISO-8859-1" encoding to be the most tolerant of special characters.  You should check-in the ".settings" file with the file whose encoding was changed.

Once the encoding is set, you should re-attempt to check-in the project.

I can't autoresolve conflicts on non-XML and non-Java files. Help!

It is only possible to auto-resolve conflicts on file types that Jazz considers to be text. If you attempt to auto-resolve a conflict on a non-text file you will see a dialog with the text:

None of these conflicts could be auto-resolved. You will have to merge them manually. The tooltip on each type of conflict provides explanations about the conflict and how to resolve them.
or:
Some of these conflicts could not be auto-resolved. You will have to merge them manually. The tooltip on each type of conflict provides explanations about the conflict and how to resolve them.

To avoid these problems, you can tell Jazz to treat the conflicted file types as text:

  1. Open "Window > Preferences > General > Content Types".
  2. In the "Content Types" pane, select "Text".
  3. Click the "Add..." button beside the "File Associations" pane.
  4. Enter the extension of the file type (such as *.html for HTML files), and click "OK".
  5. Click "OK" in the preferences dialog.

Jazz will now consider files ending with the given extension to be text. You can now auto-merge that file type.

이 게시물을...