Refactoring scenario: rename a folder

When you rename a folder in a Dimensions project with attached deployment areas, Dimensions CM also renames the folder on disk in any default deployment areas associated with the first stage. The folder continues 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 takes effect in the deployment areas for that stage. The files being deployed then appears 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 displays 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 file names 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 now are:

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