Share this page
Refactoring scenario: rename a file
When you rename a file in a Dimensions CM project with attached deployment areas, Dimensions CM also renames the file on disk in any deployment areas associated with the first stage as default areas. The file continues to use its original name in areas associated with other stages.
When you promote this change to another stage, the rename take effects in the deployment areas for that stage. At that time the old file is removed from those areas and the file is placed in the areas using the new name.
Content and name change
This example illustrates what happens if you rename a file in a project and also change its contents. Imagine a Dimensions CM project contains a file called src/main.java and there are various revisions of that file promoted to different stages.
The following table demonstrates what is in the main project and each area:
| Project | DEV | SIT | QA | LIVE |
|---|---|---|---|---|
| src/main.java;4 | src/main.java;4 | src/main.java;3 | src/main.java;2 | src/main.java;1 |
The file names are currently all the same in each area and earlier revisions have progressed further along the stage lifecycle than newer revisions.
A user then refactors the java code and renames src/main.java to src/mainevent.java (changing its content and name). Only the project and the DEV area are affected:
| Project | DEV | SIT | QA | LIVE |
|---|---|---|---|---|
| src/mainevent.java;5 | src/mainevent.java;5 | src/main.java;3 | src/main.java;2 | src/main.java;1 |
If these changes are promoted using a request to SIT, the project and area contents now are:
| Project | DEV | SIT | QA | LIVE |
|---|---|---|---|---|
| src/mainevent.java;5 | src/mainevent.java;5 | src/mainevent.java;5 | src/main.java;2 | src/main.java;1 |
The new revision is placed in SIT and the rename takes effect.
Name change only
In the scenario above, when the change was deployed, revision 3 was at SIT and was replaced by the new content (revision 5) in addition to having its name changed. It is not however necessary to change content for a file rename to be deployed.
This scenario demonstrates a rename without content change being deployed.
The following table shows what is in the main project and each area:
| Project | DEV | SIT | QA | LIVE |
|---|---|---|---|---|
| docs/login.html;4 | docs/login.html;4 | docs/login.html;4 | docs/login.html;2 | docs/login.html;1 |
The file names are currently all the same in each area, and earlier revisions have progressed further along the stage lifecycle than newer revisions.
Imagine the user then uses Desktop Client to rename docs/login.html to docs/ welcome.html. Only the project and the initial area are affected:
| Project | DEV | SIT | QA | LIVE |
|---|---|---|---|---|
| docs/welcome.html;4 | docs/welcome.html;4 | docs/login.html;4 | docs/login.html;2 | docs/login.html;1 |
Next the change is promoted to SIT, the project and area contents now are:
| Project | DEV | SIT | QA | LIVE |
|---|---|---|---|---|
| docs/welcome.html;4 | docs/welcome.html;4 | docs/welcome.html;4 | docs/login.html;2 | docs/login.html;1 |
The rename correctly takes effect in the SIT area despite the revision already being at the SIT stage.
