The following example describes a simple scenario where refactoring changes are deployed:
A project contains a file, foo.c, at revision one, foo.c;1, in directory dir1.
Two deployment areas, A1 and A2, are attached to the project. The stage is not relevant as the refactoring rules apply to the content of deployment areas.
foo.c;1 is deployed to area A1.
foo.c is updated to create revision two, foo.c;2. The tip revision of foo.c in the project is now dir1/foo.c;2.
foo.c is deployed to area A1, which now contains dir1/foo.c;2.
foo.c is updated to create revision three, foo.c;3. The tip revision of foo.c in the project is now dir1/foo.c;3.
If the tip revision is deployed to area A1, it will contain dir1/foo.c;3.
Directory dir1 is renamed to dir2 using request R1. The tip revision of foo.c in the project is now dir2/foo.c;3.
If foo.c;3 is deployed to area A1 the deployment will fail because the path in the project is ’later’ than the current path in the area. Request R1 needs to be deployed first as it contains the directory name change.
foo.c is updated to create revision four, foo.c;4. The tip revision of foo.c in the project is now dir2/foo.c;4.
foo.c;4 cannot be deployed to area A1 until request R1 is deployed.
However, foo.c;4 can be deployed to area A2 because it does not contain any revisions of foo.c. Area A2 will contain dir2/foo.c;4.
Deploying request R1 to area A2 will fail because A2 already contains the directory rename. foo.c;4 must be rolled back first.
NOTE For additional refactoring examples see Deployment and Refactoring.