Refactoring scenario: rename a folder

When you rename a folder in a Dimensions project with attached deployment areas, Dimensions CM will also rename the folder on disk in any default deployment areas associated with the first stage. The folder will continue to use its original name in areas associated with other stages.

When you use a request to track the rename, and you promote that request to another stage, the rename operation will take effect in the deployment areas for that stage. The files being deployed will then appear in the new folder.

Imagine that a Dimensions CM project contains a single folder called src containing two files (src/main.java and src/trace.java). There are various revisions of these files promoted to different stages. The following table shows 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
src/trace.java;2 src/trace.java;2 src/trace.java;2 src/trace.java;1 src/trace.java;1

The filenames and folder locations are currently all the same in each area and earlier revisions have generally progressed further along the stage lifecycle than newer revisions.

Imagine that a user then renames src to source. Only the project and the initial area are affected:

Project DEV SIT QA LIVE
source/main.java;4 source/main.java;4 src/main.java;3 src/main.java;2 src/main.java;1
source/trace.java;2 source/trace.java;2 src/trace.java;2 src/trace.java;1 src/trace.java;1

Next, you promote a request referencing the change to the folder name to SIT. The project and area contents would now be:

Project DEV SIT QA LIVE
source/main.java;4 source/main.java;4 source/main.java;4 src/main.java;2 src/main.java;1
source/trace.java;2 source/trace.java;2 source/trace.java;2 src/trace.java;1 src/trace.java;1

The src folder in the SIT area now contains no Dimensions CM-controlled files.

Back to top