How to undo all accepted changesets only from the repository and not from stream
I would like to know how to handle the following scenario in RTC
* Developer A and B are working on same stream
* Developer A has delivered a(or set of) changeset(s)
* Developer B accepts all incoming changeset(s)
* Developer B is founds out that because of the accepted changeset(s) the build is failing
Now the Developer B wants to undo all the accepted changeset(s) (only from his/her repository and not from stream) and continue with this work mainly because Developer B works on code and wants to check if that does not crash the build. Developer B cannot wait for Developer A to fix the earlier issue
How can this be achieved in RTC clients (VS as well as Eclipse)
* Developer A and B are working on same stream
* Developer A has delivered a(or set of) changeset(s)
* Developer B accepts all incoming changeset(s)
* Developer B is founds out that because of the accepted changeset(s) the build is failing
Now the Developer B wants to undo all the accepted changeset(s) (only from his/her repository and not from stream) and continue with this work mainly because Developer B works on code and wants to check if that does not crash the build. Developer B cannot wait for Developer A to fix the earlier issue
How can this be achieved in RTC clients (VS as well as Eclipse)
One answer
The only reliable approach I know of is to create a snapshot of your workspace before doing the accept. Then if you want to roll back, you would replace the contents of your workspace with that snapshot. If don't have such a snapshot, you can try to roll back by right clicking on each component in your workspace that was modified by the accept (you'll have to somehow know that), and ask for the history of that component. Then you'll have to guess what were the change sets that came in from the accept, multi-select them, and select the "discard" operation. If you hover over the change-set icon in the history view, you do get a "date added" value, which in theory should help you guess, but I have found that "date added" value to be unreliable (I've submitted work item 227537 for that issue).