Refactor projects and files in Eclipse
Refactoring includes moving or renaming projects or project elements.
For best results, follow these guidelines when performing refactoring operations:
-
Before refactoring, make sure that all users check in their changes.
-
After refactoring, make sure that all users get the updated project from source control.
Refactoring includes renaming files within a project and moving a file between two different projects. The Dimensions CM for Eclipse integration retains the file history when you move a file between projects using the refactoring option.
When performing a move between projects as part of refactoring, we strongly recommend that you set the files to be updated as part of the refactoring in Local Mode. This is not necessary when working with Dimensions CM streams.
If the files are checked out, there is a conflict with the removal of the source file from source control as part of the cross-project move operation. The checked out revision is not removed from source control, and you receive a confirmation in the console. The checked out revision remains in Dimensions CM and is picked up by subsequent project structure synchronization operations. These revisions must have the checkout canceled and be removed from the source project using the desktop client.
A particular case of this is moving a file to a different package in the second project. The Eclipse java tooling identifies that it needs to update the file with the new package name and initiates a checkout operation.
If the file is checked out, the subsequent attempt to remove it from source control doesn't remove the checked out revision. So it is better to use local mode. This makes the file writable, and the java refactoring code can update the file as part of the move to the new package in the target project. As the file is not checked out, the remove succeeds.
The same behavior applies if files are checked out by another user before performing the refactoring. The revision checked out to the other user is not removed, and a warning is issued in the console. These revisions must have the checkout canceled and be removed from the source project using the desktop client as the appropriate user.
We recommend using the Team > Refresh Project Status feature to check that files to be updated and moved are not checked out by other users (the Lock icon or layered Lock icon) or are not checked out by you and other users (the layered Check icon) before performing the refactoring.
See also: