recovering from a change
I am in this situation:
Start with Stream A containing Eclipse project "foo"
Create Stream B by duplicating Stream A
In Stream B, delete "foo" from repository
In Stream A, deliver change set modifying "foo"
Now I want to change Stream B by restoring "foo" and bringing it up to date with the latest from Stream A (without dropping other changes that are in Stream B. How do I do that?
I have a repository workspace at the latest level from Stream B. I switch its flow target to Stream A. I see an Outgoing Change Set which is the deletion of "foo". I "reverse" that change set and merge the patch into my workspace, and "foo" reappears in my eclipse workspace. I do Team -> Share Project to get it back into my repository workspace. So far so good.
Then I want to accept the incoming change set for "foo" from Stream A. This does not work. It says there is a conflict (Deleted <-> Modified). I don't see any way to resolve the conflict other than "Resolve with Mine", which ignores the incoming change set.
I seem to be stuck. The best I can think to do is bypass RTC by getting the latest version of "foo" from Stream B, copying it into my eclipse workspace, and then doing Team->Share Project. That would work but doesn't seem right, as it would lose track of the individual change set(s) that were applied in Stream A.
Start with Stream A containing Eclipse project "foo"
Create Stream B by duplicating Stream A
In Stream B, delete "foo" from repository
In Stream A, deliver change set modifying "foo"
Now I want to change Stream B by restoring "foo" and bringing it up to date with the latest from Stream A (without dropping other changes that are in Stream B. How do I do that?
I have a repository workspace at the latest level from Stream B. I switch its flow target to Stream A. I see an Outgoing Change Set which is the deletion of "foo". I "reverse" that change set and merge the patch into my workspace, and "foo" reappears in my eclipse workspace. I do Team -> Share Project to get it back into my repository workspace. So far so good.
Then I want to accept the incoming change set for "foo" from Stream A. This does not work. It says there is a conflict (Deleted <-> Modified). I don't see any way to resolve the conflict other than "Resolve with Mine", which ignores the incoming change set.
I seem to be stuck. The best I can think to do is bypass RTC by getting the latest version of "foo" from Stream B, copying it into my eclipse workspace, and then doing Team->Share Project. That would work but doesn't seem right, as it would lose track of the individual change set(s) that were applied in Stream A.
3 answers
I am in this situation:It appears you've tried to reverse the change set without success. You could try the other method, which is to discard the change set from stream.
Start with Stream A containing Eclipse project "foo"
Create Stream B by duplicating Stream A
In Stream B, delete "foo" from repository
In Stream A, deliver change set modifying "foo"
Now I want to change Stream B by restoring "foo" and bringing it up to date with the latest from Stream A (without dropping other changes that are in Stream B. How do I do that?
I have a repository workspace at the latest level from Stream B. I switch its flow target to Stream A. I see an Outgoing Change Set which is the deletion of "foo". I "reverse" that change set and merge the patch into my workspace, and "foo" reappears in my eclipse workspace. I do Team -> Share Project to get it back into my repository workspace. So far so good.
Then I want to accept the incoming change set for "foo" from Stream A. This does not work. It says there is a conflict (Deleted <-> Modified). I don't see any way to resolve the conflict other than "Resolve with Mine", which ignores the incoming change set.
I seem to be stuck. The best I can think to do is bypass RTC by getting the latest version of "foo" from Stream B, copying it into my eclipse workspace, and then doing Team->Share Project. That would work but doesn't seem right, as it would lose track of the individual change set(s) that were applied in Stream A.
https://jazz.net/library/article/126#How_do_I_remove_a_change_set_fro
It is described in the FAQ (the second part of the answer).
The reverse operation did work, but resulted in creating a patch that added back what was deleted.
It appears that RTC "remembers" that foo was deleted, and then re-added, and later, when trying to accept additional changes to foo from Stream A, where this deletion / readdition did not occur, treats this additional change as a change to the "original" foo - which it then realizes in stream B was "deleted".
The problem with alternative #2 ( resetting Stream B back to a point prior to the deletion ) , is that this drops all change sets that happened after the foo deletion. So that doesn't really work, either.
Other ideas?
It appears that RTC "remembers" that foo was deleted, and then re-added, and later, when trying to accept additional changes to foo from Stream A, where this deletion / readdition did not occur, treats this additional change as a change to the "original" foo - which it then realizes in stream B was "deleted".
The problem with alternative #2 ( resetting Stream B back to a point prior to the deletion ) , is that this drops all change sets that happened after the foo deletion. So that doesn't really work, either.
Other ideas?
In alternative #2, you don't reset Stream B back to the point prior to
the deletion ... you just discard the change-set that performed the
deletion (and keep all the change-sets after that).
In particular:
- Create a workspace on Stream B, ask for the history of the component
in that workspace, right click on the change-set that deleted foo, and
select "discard".
- Right click on the component in that workspace and do a "replace in
stream" operation.
This will undo that project delete, while keeping any other changes that
you have done in Stream B.
Cheers,
Geoff
On 9/30/2011 5:08 PM, marshallschor wrote:
the deletion ... you just discard the change-set that performed the
deletion (and keep all the change-sets after that).
In particular:
- Create a workspace on Stream B, ask for the history of the component
in that workspace, right click on the change-set that deleted foo, and
select "discard".
- Right click on the component in that workspace and do a "replace in
stream" operation.
This will undo that project delete, while keeping any other changes that
you have done in Stream B.
Cheers,
Geoff
On 9/30/2011 5:08 PM, marshallschor wrote:
The reverse operation did work, but resulted in creating a patch that
added back what was deleted.
It appears that RTC "remembers" that foo was deleted, and
then re-added, and later, when trying to accept additional changes to
foo from Stream A, where this deletion / readdition did not occur,
treats this additional change as a change to the "original"
foo - which it then realizes in stream B was "deleted".
The problem with alternative #2 ( resetting Stream B back to a point
prior to the deletion ) , is that this drops all change sets that
happened after the foo deletion. So that doesn't really work,
either.
Other ideas?