Bug 146976 Save state of the report not correct.
Reproduce: 1) New a library "lib1", add a label "label1" 2) Publish "lib1" 3) New a report "report1", use "lib1" 4) Drag "lib1.label1" into "report1" 5) Go back to "lib1", drop "label1", save and publish again. 6) Go to "report1", refresh the libaray explorer and design. 7) Save "report1" 8) Now, we go back to "lib1" 9) Undo the previous "delete command", "label1" is added back. 10) Save "lib1", and re-publish. 11) Go to "report1", refresh the libaray explorer and design. 12) Save "report1" At this stage, "report1" is saved, but the dirty indicator(*) still displayed in the left side of the report name. I am testing on build N20060613
model/org.eclipse.birt.report.model/src/org/eclipse/birt/report/model/activity/ActivityStack.java
* is undone, it will find that the model is not in the expected final state for
 * record C, and thus there is no guarantee that doing the undo will leave the
 * model in either the initial state or even a valid state.
 * <p>
 * It is for this reason that executing a record must flush the redo stack. The
 * effect of the new record is to move the model to a state different than the
 * final state of the first record on the redo stack. Hence, that record can no
 * longer be redone and must be flushed.
 * <p>
 * Similarly, the record system works only if all changes to the model are done
 * through records. Suppose that some change is made without a record. The
 * result is that the model has changed from state Sn to state Sn+1. However,
 * the record at the top of the undo state still expects the model to be in its
 * final state: state Sn.
 * 
 * <h3>Notifications</h3>
 * 
 * The stack is responsible for sending out notification events as records
 * execute (do, undo or redo). Each record sends out a notification event at the
 * request of the stack. ActivityRecord in the stacks have a state that must
 * match the stack on which they appear. The state is used to compute
 * notification events for the record.
 * <p>
 * Notifications are sent as soon as a record is executed, even in the case of a
 * transaction. An alternative (more complex) implementation could provide an
 * additional hint to the UI that a transaction is in effect so that the UI can
 * batch up updates without repeating the same update unnecessarily. This
 * advanced mechanism would require some kind of "end update" event to be sent
 * to every listener that received a notification. Such a mechanism is beyond
 * the scope of this initial implementation, but can be added later if a proven