Description Darin Wright 2005-10-28 09:41:38 EDT

Currently, when a breakpoint refactoring is undone, the breakpoint is simply 
deleted. Not ideal, but due to the following limitation reported in bug 114081.

The problem is an assumption in the perform method of the change objects of the
debug rename participants: An IResource for the new element is retrieved and
used to create a new breakpoint, but in case of an undo the resource does not
(yet) exist.

This is not a problem during normal execution: There, the participant changes
get executed AFTER the refactoring changes, thus the new renamed element 
exists,
and so does its resource.

However, when performing the undo change, the order is reversed: The 
participant
changes get executed BEFORE the refactoring changes, thus the new renamed
element does not exist, and the resource does not exist either.

The undo change should probably be changed back to a NullChange for M3. A real
solution would either require code without assumptions about element existence
or reversing the execution order (for example, on participant request).