Merge work items and change sets from one repo to another

If I understand correctly, the capability is still not available to merge data from one RTC2.0 repositorry into anoter. That said, if a client really wants to migrate work ietms and source code change sets from one RTC2.0 repository into another RTC2.0 repository (both repos have production data), what could be the workarounds? Thanks.

I don't think there is a workaround here but very interested if you find one! However, I know there is work being done on repo merges and/or transfering projects from one repo to another.

anthony

A workaround for moving a work item from one repository to another would
be to export the work item from one repository, and import it into the
other repository (of course, only the information captured by the export
would make it across).

A workaround for moving change sets from one repository to another is to
create a "patch", and then apply that patch to the other repository.

Cheers,
Geoff

yanli wrote:

If I understand correctly, the capability is still not available to
merge data from one RTC2.0 repositorry into anoter. That said, if a
client really wants to migrate work ietms and source code change sets
from one RTC2.0 repository into another RTC2.0 repository (both repos
have production data), what could be the workarounds? Thanks.

The workaround suggested works fine for a limited number of elements after some manual work, however using this approach to migrate the data of one project area on server A to a second project area on server B has the following challenges:

* The work around do not allow to migrate the history of a component, file or repository workspace. All the history is lost. It only resolves those changes not delivered to the stream.
* Work items cross references are lost (depends, blocks, mentions, ).
* Work items attachments are lost.
* Work items changes sets are lost.
* Of course work items IDs change after importing them, although theres no way to fix the as the work item number is a unique identifier and the ID of the migrated work item may be already in use on the target server, regardless of the migration mechanism used.

So, from the point of view of migration completeness, I would say that the workaround suggested covers 0% of the requirements for the source code and 50% of the requirements for the work items.

For a massive migration I would recommend to do it at the beginning of a new iteration (release) to just include the latest version from the source code and to just migrate the unresolved work items planned for the future, fixing manually the information that gets lost.

A workaround for moving a work item from one repository to another would
be to export the work item from one repository, and import it into the
other repository (of course, only the information captured by the export
would make it across).

A workaround for moving change sets from one repository to another is to
create a "patch", and then apply that patch to the other repository.

Cheers,
Geoff

yanli wrote:

If I understand correctly, the capability is still not available to
merge data from one RTC2.0 repositorry into anoter. That said, if a
client really wants to migrate work ietms and source code change sets
from one RTC2.0 repository into another RTC2.0 repository (both repos
have production data), what could be the workarounds? Thanks.

Yes, the work around proposed earlier is for a limited number of
elements. It obviously is not a "migration solution", much less a
"massive migration" solution.

For a migration solution, you would need to use the Team Concert
synchronizer or importer technology provided. Rational and its partners
have build several synchronizers and importers, and provides a
synchronizer framework that can be used to build your own synchronizers.
Work is also being done on the importer framework to make it more
reusable.

Cheers,
Geoff


carlos.cid wrote:

The workaround suggested works fine for a limited number of elements
after some manual work, however using this approach to migrate the
data of one project area on server A to a second project area on
server B has the following challenges:

* The work around do not allow to migrate the history of a component,
file or repository workspace. All the history is lost. It only
resolves those changes not delivered to the stream.
* Work items cross references are lost (depends, blocks, mentions,
).
* Work items attachments are lost.
* Work items changes sets are lost.
* Of course work items IDs change after importing them, although
theres no way to fix the as the work item number is a unique
identifier and the ID of the migrated work item may be already in use
on the target server, regardless of the migration mechanism used.

So, from the point of view of migration completeness, I would say that
the workaround suggested covers 0% of the requirements for the source
code and 50% of the requirements for the work items.

For a massive migration I would recommend to do it at the beginning of
a new iteration (release) to just include the latest version from the
source code and to just migrate the unresolved work items planned for
the future, fixing manually the information that gets lost.

gmclemmwrote:
A workaround for moving a work item from one repository to another
would
be to export the work item from one repository, and import it into
the
other repository (of course, only the information captured by the
export
would make it across).

A workaround for moving change sets from one repository to another
is to
create a "patch", and then apply that patch to the other
repository.
Cheers,
Geoff

yanli wrote:
If I understand correctly, the capability is still not available to
merge data from one RTC2.0 repositorry into anoter. That said, if
a
client really wants to migrate work ietms and source code change
sets
from one RTC2.0 repository into another RTC2.0 repository (both
repos
have production data), what could be the workarounds? Thanks.