It's all about the answers!

Ask a question

Refactoring across components


Daniel Toczala (88211514) | asked Feb 04 '09, 12:38 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
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



permanent link
Geoffrey Clemm (30.1k33035) | 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
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.

permanent link
Fredrik Gustavsson (211) | answered Aug 13 '10, 1:35 p.m.
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:
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

permanent link
Geoffrey Clemm (30.1k33035) | 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
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

gmclemmwrote:
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

permanent link
Fredrik Gustavsson (211) | answered Aug 18 '10, 1:13 p.m.
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
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

permanent link
Geoffrey Clemm (30.1k33035) | 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
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

gmclemmwrote:
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


permanent link
Fredrik Gustavsson (211) | answered Aug 30 '10, 11:14 a.m.
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
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

Your answer


Register or to post your answer.