Probably the simplest approach would be to just have the test project
area in the production repository, and then have the production project
area "share" the process configuration of the test project area when you
are ready to go live with the revised process configuration.

Note: You'll want to have at least two test project areas ... one that
is currently in use in production, and one that you are modifying. Or
you could freeze a test project area once it goes into production, so
you can more easily browse through previous releases of the process
configuration.

Or if you want to do all your testing in a separate repository, you can
do so, and when you are happy with the test project configuration,
export it as a template, and import that template into a new project
area in the production repository (and then update your production
project area to share the process configuration of that new project area).

This is streamlined in the 2012 release, where a project area will be
able to share the process configuration of a project area in another
repository.

Cheers,
Geoff

On 12/16/2011 6:08 AM, theju wrote:

Hi,

Like how we first upgrade test DB in CQ to test changes, how to
acheive the same in RTC. A thought from my side:

Create a test RTC project that mimics the production RTC project. Do
the change (say, some WI customization) first in the test project and
repeat the same in the production RTC project. Do this for every
change. Or, do all the changes in the test project and copy and paste
the XML source from the test RTC project to the production RTC
project.

Is there a bettter way to mimic the CQ kind of testing on test DB
first before pushing the changes to prod DB?

Thanks!