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
* <p>
 * As a convenience for the application, the compound record implementation is
 * abstracted into the concept of a <em>transaction</em>. The application
 * simply calls startTrans( ) to start a series of operations to be treated as
 * atomic, and calls commit( ) to complete the series. For convenience,
 * transactions can nest to any depth. Only the outermost transaction shows up
 * as a an undoable or redoable record in the UI.
 * <p>
 * It is important to understand when records execute within a transaction.
 * Records execute during the call to execute( ) on the record stack. That is,
 * whether or not a record is part of a transaction, it executes immediately
 * when added to the record stack. Note that this model differs from other
 * systems, such as GEF, that defers execution of nested records until the
 * compound record itself executes. However, the incremental execution model of
 * this implementation means that the application need not know whether a record
 * is part of a transaction or not, the effect on the model state is identical.
 * This model is important to allow code to work directly with the model,
 * knowing that the model reflects the series of records executed previously.
 * 
 * <h3>Error Handling</h3>
 * 
 * The record stack is a low-level operation primarily responsible for managing
 * record history. Records are defined to always work. That is, when a record is
 * told to execute, undo or redo, the record operation must succeed. If there
 * are issues that might prevent the execution from succeeding, they must be
 * checked by the application <em>before</em> issuing the record. If a record
 * returns true from canUndo( ), then it must successfully undo, assuming that
 * the state of the model is correct. Similarly, if a record returns true from
 * canRedo( ), then the redo must succeed, again assuming the model state is
 * valid. The only way the model state could be invalid is due to a programming