Is it possible to discard not accepted incoming changes
My customer develops one application that is used by several other applications. Due to these other applications requirements, my customer has more than one version of this application in PRODUCTION.
Lets assume (as an example) they have "app v 1.0 and app v2.0 in Production. The developers make changes in both versions. They have two different streams: one for app v1.0 and another one for app v2.0. Whenever they fix an error in app v1.0 they need to propagate it to app v 2.0. In order to do so, I have recommended them to deliver the fix to the "app v 1.0" stream, create a repository workspace for app v1.0 and load it with app v 1.0 stream content. Then change the flow target so this workspace points to the app v2.0 stream. Doing so they can deliver the fix from "app v.1.0 " to app v.2.0 stream. In this scenario, all the changes that were developed in app v 2.0 but not in app v 1.0 appear in the pending changes view as incoming changes of the app v 1.0 workspace. If I am not wrong, it is not possible to discard incoming changes unless you have already accepted them. So I have two questions: 1- is there any way to make this incoming changes disappear from the pending changes view, or manage them without accepting them? 2- is the solution I proposed the best one for their needs, or is there another better approach? Any hint would be much appreciated, Maria Jose |
5 answers
Hi Maria,
I do believe it is possible to deliver the v1.0 changes to v2.0 without accepting incoming changes from v2.0. However, conflicts would require that they be resolved and this is a part of porting changes between streams. It's likely that integrating changes from another stream will require some conflict resolution and there really isn't a way to avoid it. If there is no conflict, you should be able to deliver the changes without accepting incoming changes. Are you seeing conflicts when redelivering changes to another stream? This would explain why you cannot deliver without accepting and merging changes. Hope that helps, Tim |
|
Thanks for your answer, Tim.
I will try to clarify a little more my question. It was not precise enough :=) You are right: RTC allows to deliver outgoing changes from v 1.0 workspace to v 2.0 stream even if you have not accepted incoming (from 2.0) changes in 1.0 workspace. Thats fine. And I am aware that when delivering a fix that contains files that have also being changed in v 2.0 stream, resolving conflicts before delivering the fix is mandatory. RTC preserves the code integrity when doing parallel development. I dont intend to avoid this. But my point refers to the incoming changes that have no conflict with the outgoing changes: I dont want to propagate these changes to v 1.0 workspace. RTC shows every incoming change and it is not possible to know if the change will generate a conflict until you try to deliver it, but not in advance. So maybe it makes no sense to make these incoming disappear from the pending changes view. Keeping there the developer is aware of all the changes in v 2.0, even he/she does not want to accept them in v 1.0. :?: :D Thanks in advance. |
|
I think I understand a little bit more about how you want to avoid delivering 2.0 changes to your 1.0 stream. Once you change flow targets with your 1.0 workspace to your 2.0 stream, delivered change sets will only go to the 2.0 stream. If you make any changes to the 1.0 workspace (such as accepting 2.0 change sets or merging code), it only affects the 1.0 workspace. When you switch the flow target back to the 1.0 stream, those changes will appear as outgoing and may be discarded from the workspace. They will not disappear from the 2.0 stream and will not be delivered to the 1.0 stream.
Perhaps it would be easier to flow change sets if you look at it from a different direction. Create a remote workspace from the 2.0 stream and change the flow target to the 1.0 stream. All the new features in 2.0 will be shown as outgoing but all you want to do is concentrate on accepting the fixes in 1.0. Accept the fixes and do any necessary merges before switching flow targets back to the 2.0 stream to deliver. This way all the fixes go into the workspace first. The merges can be tested before delivering to the 2.0 stream. |
Geoffrey Clemm (30.1k●3●30●35)
| answered Dec 23 '09, 12:53 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I don't believe this use case is currently supported in Team Concert (in
ClearCase, for example, you would add a merge hyperlink from the version you want to ignore to the current version). I've submitted work item 102223 for this feature. What you are currently doing is the standard way to flow change-sets from one stream to another. To handle this use case, the only thing that occurs to me at the moment is to record in the description of your workspace the ID of the latest change set that you've "ignored", and make sure you never deliver that change-set or any ones prior to it in the history of the workspace. Cheers, Geoff mjarbulu wrote: My customer develops one application that is used by several other |
|
Tim, thanks a lot for your hint about "looking at it from a different direction". We are using this process to propagate fixes from v 1.0 to v 2.0. From the SCM point of view is a very good solution and my customer is very happy with it.
Geoffrey, thanks a lot for submitting work item 102223. I think it is a very valuable and useful feature. I think I understand a little bit more about how you want to avoid delivering 2.0 changes to your 1.0 stream. Once you change flow targets with your 1.0 workspace to your 2.0 stream, delivered change sets will only go to the 2.0 stream. If you make any changes to the 1.0 workspace (such as accepting 2.0 change sets or merging code), it only affects the 1.0 workspace. When you switch the flow target back to the 1.0 stream, those changes will appear as outgoing and may be discarded from the workspace. They will not disappear from the 2.0 stream and will not be delivered to the 1.0 stream. |
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.