copy componnet include its history to another project
Hi ,
I want to copy component + his files history + component baseline history to another project , is there a way to do that ? I am using RTC 3.0.1 Thanks, Mickey |
6 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Apr 04 '12, 11:51 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
For this kind of testing, I would strongly recommend doing it in another repository (which you can then throw away), rather than cluttering up your production environment with these copies. And then you can use the distributed SCM functionality to create those copies.
Now for the particular use case you are trying to figure out. What you really need is work item 128329: Need to be able to handle "gaps" via standard accept mechanism, and not "patch" mechanism This unfortunately did not make the 4.0 plan, but is very high priority for the next release after 4.0 (but it wouldn't hurt to add a comment to that work item indicating your interest/support). Until that is available, what you propose to do below is about the best you can do. Note that you will want to first delete everything in your sandbox before copying over the contents of 3.0, in order to capture any file deletions that have occurred. Also, note that the main problem with this approach is that it will not notice file moves/renames, and instead, will treat them as a deletion of the source file and the creation of a new target file. This means, for example, that if there is a subsequent modification to a moved/renamed file in 2.1, that when you accept that change into a 3.0 workspace, you will get a "changed/deleted" conflict, and will have to go find where that file got moved to in order to apply that change. Whether or not this is a problem then depends on how often this situation arises in practice. Cheers, Geoff I forgot to mention why we need the test environment: Hi Geoff, If you are just doing some testing, then I'd recommend doing it on another server anyway. In which case, you can use the distributed SCM capabilities mentioned below to copy the streams over. Just for interest's sake, what kind of testing are you doing that requires having a copy ? Yes, it is project area on the same server . By "project", do you mean "project area"? Hi , |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Apr 03 '12, 1:03 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
By "project", do you mean "project area"?
If so, if the two project areas are on the same server, there is no need to do any copying ... the second project area can just reference the component (with its files and baseline history). If the two project areas are on different servers, then you would use the distributed SCM capabilities of RTC to deliver the streams you want to the other server. That will copy over the component and the file/folder history, but I believe it does not copy over baseline history (not positive about that). Cheers, Geoff Hi , |
|
Yes, it is project area on the same server .
But I do want to do a real copy of the component. My purpose it to create the same picture in one project area to the other project area for testing purpose project . Thanks, Mickey By "project", do you mean "project area"? Hi , |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Apr 04 '12, 12:20 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
If you are just doing some testing, then I'd recommend doing it on another server anyway. In which case, you can use the distributed SCM capabilities mentioned below to copy the streams over. Just for interest's sake, what kind of testing are you doing that requires having a copy ?
Cheers, Geoff Yes, it is project area on the same server . By "project", do you mean "project area"? Hi , |
|
Hi Geoff,
I hope to to make it simple . We had migrated from Synergy to RTC before 2 month . We decide to migrate in additional to the current development tree as well development trees that were released that already in the field . We migrate the development trees as they are in Synergy history. Currently this is the stream picture : (1.0 - 2.2 were release before migrate to RTC ) 1.0 -> 2.0 -> 2.1 -> 2.2 -> 2.2.1 2.0 -> 3.0 (current development) When we trying to deliver fixes that we are doing on 2.2.1 to 3.0 ,it give us errors about gab in the history . We figure out that we first have to accept change-sets form 2.1 and 2.2 on 3.0 stream in order to deliver change-sets from 2.1.1 . The problem that this change-sets from release 2.1 and 2.2 are big and contain dozens of files ,since this the way we brought changes to RTC between releases This mean that if I need to deliver one change-set from 2.1.1 -> 3.0 with one file it will depend on change-set from 2.1 or 2.2 with dozens of files that have no logical relate between them Thanks, Mickey If you are just doing some testing, then I'd recommend doing it on another server anyway. In which case, you can use the distributed SCM capabilities mentioned below to copy the streams over. Just for interest's sake, what kind of testing are you doing that requires having a copy ? Yes, it is project area on the same server . By "project", do you mean "project area"? Hi , |
|
I forgot to mention why we need the test environment:
We want take all change-sets from 2.1 2.2 and 2.2.1 and accept them in 3.0 ( although we do not really what the content of the files )and resolve all conflict with " resolve with mine" Once we took all change-sets we will overwrite all updated file again with 3.0 files . Is that make sense to you ? any idea how we can workaround it ? currently we are not able to deliver change-sets from 2.1.1 to 3.0 . Thanks, Mickey Hi Geoff, If you are just doing some testing, then I'd recommend doing it on another server anyway. In which case, you can use the distributed SCM capabilities mentioned below to copy the streams over. Just for interest's sake, what kind of testing are you doing that requires having a copy ? Yes, it is project area on the same server . By "project", do you mean "project area"? Hi , |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.