Refactoring across components
Is it possible to refactor across components? I know that you can refactor a single component into multiple components (https://jazz.net/help/rational-team-concert/1.0.1/index.jsp?topic=/com.ibm.team.scm.doc/topics/t_scm_eclipse_components_streams.html), but is it possible to refactor into another already existing component.
|
6 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Feb 05 '09, 12:48 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Yes, it is possible to refactor into an already existing component. In
fact, that is what you must do. I.e. you have to create the new component before you can move any projects/files into it. One caveat in general about moving files between components: A change-set is tied to a particular component. In particular, suppose that in one workspace/stream, you have some file in componentA. Now suppose that in some other workspace/stream, you move/refactor that file into componentB. Now suppose you make a change to that file in the first workspace/stream (i.e. where that file was in componentA), and that you accept that change-set into the other workspace/stream (where that file is in componentB). That change will not be applied to the file in its new location. Instead, you will get a "delete/modify" conflict in its original location. Cheers, Geoff dtoczala wrote: Is it possible to refactor across components? I know that you can |
I ran into this situation, having one component that has been broken up into two and now wanting to apply a change-set that was created before that refactoring (and affecting both current components).
Are there any recommendations for how to handle a case like this? Thanks Fredrik One caveat in general about moving files between components: |
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 13 '10, 4:52 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The only way I know to do this is to create a "patch" for the change-set
you want to apply (RTC has a "create patch" operation on a change set), and then apply that patch to the files in their new location. Anyone else have a better way? Cheers, Geoff On 8/13/2010 1:37 PM, fredrikg wrote: I ran into this situation, having one component that has been broken |
I tried to bring over the changes with a patch, however the patch generation didn't account for the "Move in repository" operations that I did for the refactoring. This resulted in that the pathnames inside the patch were based on the delivering stream and not the receiving stream.
After modifying the patch itself with the new pathnames I was able to apply it successfully. There's still a couple of problems in using the patch mechanism: - how to handle binary files (e.g. jar files, gif/jpg images), in my case all trivial merges - how to clear out the change sets that were delivered using the patch Regards Fredrik The only way I know to do this is to create a "patch" for the change-set |
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 28 '10, 12:35 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
WRT the first problem, I've submitted work item 128328 (Need "patch" to
handle binary files). WRT the second problem, I wasn't quite sure what you wanted to clear out from where. Could you provide some more details? In particular, I assume you want to adjust what you are seeing in your pending changes view, correct? You might be asking for 102223 (Allow the user to specify a list of change sets that should be "ignored" as incoming changes), but I'd need some more details to make sure. Cheers, Geoff On 8/18/2010 1:22 PM, fredrikg wrote: I tried to bring over the changes with a patch, however the patch |
Thanks Geoff!
The first problem is fully covered in the work item raised (128328). The relation to patching due to "gaps" is valid but there are other reasons as well. Such as patching as the only option due to change sets spanning multiple components due to refactoring. The second problem is covered in 128329. I'm looking for a solution where traceability is maintained when applying change sets using patching in the same way as with an RTC accept. Currently, the change sets are still shown as incoming even after the patch has been applied. 102223 might be used as a workaround but, as I understand, that proposed solution introduces a separate step that could be error prone. WRT the first problem, I've submitted work item 128328 (Need "patch" to |