Merging streams when some project changed hosting components
I put myself in a bit of a situation in regards to the stream management of my team's main project.
our setup is made of a main development stream and several support streams for already released versions of the product. When a maintenance release ships out from on of the support stream, we tend to push the fixes up on to the dev stream.
Unfortunately, one of the refactorings that was carried out on the dev stream led to move some of the projects to different components (... that plus some renaming, splitting ...)
This led the merging process to become near impossible. Note that i usually merge by loading the stream to which i will merge to, switch the flow to the stream that currently holds the changes to merge, accept those changes, try to resolves the conflicts, switch the flow back to the target stream and deliver ).
Because of this changes in the hosting components, I get a lot of "unparented" resources. There is a feature of the patch tool to "change the target" of those unresolved changes but since the patch tool doesn't show the original path of the resource affected by the change, it is impossible to find where to map the change to when the resource hasn't got a reasonably unique name (e.g. plugin.xml, build.xml, ...).
Is there any way to get around this hurdle?
best regards,
david.
our setup is made of a main development stream and several support streams for already released versions of the product. When a maintenance release ships out from on of the support stream, we tend to push the fixes up on to the dev stream.
Unfortunately, one of the refactorings that was carried out on the dev stream led to move some of the projects to different components (... that plus some renaming, splitting ...)
This led the merging process to become near impossible. Note that i usually merge by loading the stream to which i will merge to, switch the flow to the stream that currently holds the changes to merge, accept those changes, try to resolves the conflicts, switch the flow back to the target stream and deliver ).
Because of this changes in the hosting components, I get a lot of "unparented" resources. There is a feature of the patch tool to "change the target" of those unresolved changes but since the patch tool doesn't show the original path of the resource affected by the change, it is impossible to find where to map the change to when the resource hasn't got a reasonably unique name (e.g. plugin.xml, build.xml, ...).
Is there any way to get around this hurdle?
best regards,
david.
3 answers
Unfortunately, I am not aware of any support for this currently. There
is an old work item (21636) requesting support for this, and I've added
a comment to that work item indicating that you encountered this
problem. Please add your own comment to the work item to further
describe your situation, or just to add your support.
I personally believe this is an important feature, for anyone who is
refactoring files/directories into a different component.
Cheers,
Geoff
david.brpr wrote:
is an old work item (21636) requesting support for this, and I've added
a comment to that work item indicating that you encountered this
problem. Please add your own comment to the work item to further
describe your situation, or just to add your support.
I personally believe this is an important feature, for anyone who is
refactoring files/directories into a different component.
Cheers,
Geoff
david.brpr wrote:
I put myself in a bit of a situation in regards to the stream
management of my team's main project.
our setup is made of a main development stream and several support
streams for already released versions of the product. When a
maintenance release ships out from on of the support stream, we tend
to push the fixes up on to the dev stream.
Unfortunately, one of the refactorings that was carried out on the dev
stream led to move some of the projects to different components (...
that plus some renaming, splitting ...)
This led the merging process to become near impossible. Note that i
usually merge by loading the stream to which i will merge to, switch
the flow to the stream that currently holds the changes to merge,
accept those changes, try to resolves the conflicts, switch the flow
back to the target stream and deliver ).
Because of this changes in the hosting components, I get a lot of
"unparented" resources. There is a feature of the patch
tool to "change the target" of those unresolved changes but
since the patch tool doesn't show the original path of the resource
affected by the change, it is impossible to find where to map the
change to when the resource hasn't got a reasonably unique name (e.g.
plugin.xml, build.xml, ...).
Is there any way to get around this hurdle?
best regards,
david.
Please also read Geoffrey's answer as there still remains an open defect for merging cross-component conflicts (provide support for cross-component conflicts (21636))
Since in your question you describe missing parents/folders and the need to patch due to gaps, the following information may be useful:
In RTC 4.0.5 we delivered additional support when trying to accept change sets which have a gap (often encountered when trying to backport fixes). In a very brief summary of the feature, when you accept change sets with a gap, you can now follow a gap workflow that accepts one change set at a time and, for change sets that contain gaps, creates a new change set (with aided traceability), that contains the equivalent changes. This means users will not have to accept the change sets 'as a patch'. Applying change sets as a patch has limitations compared to the new workflow (as discussed in the article below).
This feature is summarized in the RTC 4.0.5 'New & Noteworthy' page: https://jazz.net/downloads/rational-team-concert/releases/4.0.5?p=news#scm-improve-usability-405-m1
Below are some videos which show this feature:
-Accepting multiple change sets with gaps in the RTC 4.0.5 client for Eclipse IDE: https://www.youtube.com/watch?v=28raag5RdzU
-Accepting a change set with a gap in the RTC 4.0.5 client for Eclipse IDE: https://www.youtube.com/watch?v=TucVu_BgB7E
Also, in RTC 5.0 we added a "fill the gap" feature where the change sets that fill the gap are shown to the user, allowing them to either accept all the change sets or to continue with the gap workflow that was available in RTC 4.0.5.
This feature is summarized in the RTC 5.0 'New & Noteworthy' page: https://jazz.net/downloads/rational-team-concert/releases/5.0?p=news#eclipse-fill-gaps
Both features are explained in detail in the "Improved Gap Handling for SCM" article: https://jazz.net/library/article/1372
Note: This new gap workflow makes it easier to deal with structural conflicts (ex: missing parents, moves, name conflicts etc.) which is the main part of your question. Please open a new forum question with any difficulties when using the new Gap workflow.
Since in your question you describe missing parents/folders and the need to patch due to gaps, the following information may be useful:
In RTC 4.0.5 we delivered additional support when trying to accept change sets which have a gap (often encountered when trying to backport fixes). In a very brief summary of the feature, when you accept change sets with a gap, you can now follow a gap workflow that accepts one change set at a time and, for change sets that contain gaps, creates a new change set (with aided traceability), that contains the equivalent changes. This means users will not have to accept the change sets 'as a patch'. Applying change sets as a patch has limitations compared to the new workflow (as discussed in the article below).
This feature is summarized in the RTC 4.0.5 'New & Noteworthy' page: https://jazz.net/downloads/rational-team-concert/releases/4.0.5?p=news#scm-improve-usability-405-m1
Below are some videos which show this feature:
-Accepting multiple change sets with gaps in the RTC 4.0.5 client for Eclipse IDE: https://www.youtube.com/watch?v=28raag5RdzU
-Accepting a change set with a gap in the RTC 4.0.5 client for Eclipse IDE: https://www.youtube.com/watch?v=TucVu_BgB7E
Also, in RTC 5.0 we added a "fill the gap" feature where the change sets that fill the gap are shown to the user, allowing them to either accept all the change sets or to continue with the gap workflow that was available in RTC 4.0.5.
This feature is summarized in the RTC 5.0 'New & Noteworthy' page: https://jazz.net/downloads/rational-team-concert/releases/5.0?p=news#eclipse-fill-gaps
Both features are explained in detail in the "Improved Gap Handling for SCM" article: https://jazz.net/library/article/1372
Note: This new gap workflow makes it easier to deal with structural conflicts (ex: missing parents, moves, name conflicts etc.) which is the main part of your question. Please open a new forum question with any difficulties when using the new Gap workflow.