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
* need arises.
 * <p>
 * Notifications are easiest to manage if each record affects a single element
 * called the target element. This is the element that will broadcast
 * notifications. The {@link AbstractElementRecord simple record}class
 * automates notifications for this case. More complex implementations are
 * possible, but the use of a transaction (or compound record) may be simpler in
 * many cases.
 * 
 * <h3>Scope of Change and Transactions</h3>
 * 
 * Each record affects a single element. However, many application-level
 * operations affect multiple elements. For example, an element may be
 * referenced by multiple elements. If the application wants to delete this
 * element, it must first remove the references, then do the deletion. Removing
 * references affects other elements, and so must be done as separate records.
 * Still, from the user perspective, the entire operation is an atomic
 * operation, to be undo and redone together. The solution is to use a
 * <em>compound record</em>. The compound record is undone and redone as
 * unit. The detailed operations are automatically performed in the proper
 * order.
 * <p>
 * Above we said that a record must leave the model in a valid state. This rule
 * applies only to top-level records. It is expected that the model may be in an
 * intermediate state during part of a compound record. For example, suppose we
 * want to delete an element E that is referenced by three other elements. We
 * would implement this as a compound record. The first three sub-records would
 * remove the references to E. Then, the final sub-record would delete E itself.
 * The initial and final states of the overall compound record are valid, but
 * the states between sub-records are not necessarily valid.