>> I do like what you're trying to do here in terms of streamlining the
>> Review & Save use-case.  How about, upon clicking Save, it simply
>> re-snapshots the package, then enumerates the definitions and
>> re-ignore the ones which the user said to (I)gnore the first time and
>> re-ignore them just before saving?
>
> I have to think about that.

The goal is to streamline the Review & Save use-case so we don't have
to click two buttons (Changes and Save) to open two windows up every
time.  Is that right?

But by not allowing *corrections* to methods during Review, it
actually makes things a lot worse.  Let's detail the process steps of
the Review & Save use-case.  First with what we have today:

   1) click the Save button.
   2) click the Changes button.
   3) review the changes, typing release-notes text as you go.  Make
any necessary improvements right then and there based on the review.
           (3.1)   -- If the phone rings, pick up the phone and have a
conversation --.)
   4) click the Ok button and be assured, everything that was reviewed
and corrected is now saved.  Serenity!

With Monticello-bf.532.mcz here are the steps:

   1) click the Save button.
   2) review the changes, typing release-notes text as you go.  Make
any necessary improvements right then and there based on the review.
   3) if no changes were made, skip to step 8.
   4) copy the release-notes to the clipboard,
   5) click the Cancel button to close the Save window,
   6) click the Save button again to reopen it.
   7) re-paste the release-notes text.
             (7.1)  -- If the phone rings, pick up the phone and have
a conversation --.)
   8) click "Ok" this time to save what was listed in the.
   9) Feel insecure about whether all the review updates are, in fact,
saved.  Stress!  Better double check, step 10??

The irony is that by every effort to integrate Review+Save, they are
being made wholly separate activities; exactly the opposite of the
intended goal.

> Maybe the best of both worlds would be if any change done while the save dialog is open would be added to the changes list automatically? Not sure how to implement that though, MC is thoroughly snapshot-based, and taking a snapshot is not cheap.

No, the solution is to simply do what we have today.


> Easier to implement might be to warn about intermediate changes.

No, we need to be moving toward a _less_ rather than more intrusive
UI.  Warnings create a modal situation and end up getting ignored.
The user must stay in control.  See

    http://en.wikipedia.org/wiki/The_Humane_Interface

> Upon accepting the save dialog I snapshot the package anyway,

Yes!

> to mark the working copy dirty or clean. If this snapshot differs from the earlier snapshot, it could bring up a
> warning.

No!

> Or even better, it could update the changes list with the current one. How does that sound?

Yes, we must preserve the original save behavior by taking a final
snapshot and if you want that new (I)gnore feature, then simply let
that function capture the #description of the Definitions being
ignored.  Then when the user clicks OK on the Save dialog, after the
new snapshot, THEN enumerate those definitions of the new snapshot and
skip the ones whose description matches the ones previously ignored.

This way the acts of Reviewing and Saving can truly be integrated into
one step.  Thanks.