So what I think is really needed is to ADD what you get when you press
the "Changes" button directly TO the save dialog (on the right half).
Because looking at the changes is what we *always* do in conjunction
with saving a package; otherwise it becomes a window-focus fight.

  - Click "Changes".  Patch browser window opens.
  - Click "Save".  Position the window next to changes so I can toggle
back and forth, entering the descriptive "whys" of what's being done.
  - Click back on Patch browser window to arrow through the list...

How nice it would be to just have the selectable list off to the right
(above?  below?) of the text box where the version information is
entered.  Literally, both panes of the Patch browser, the list in the
top half, code pane in the bottom half, with the full context menu
available!

Since both views are already written and disconnected; I thought it
would be a piece of cake to do?  But this is where I've never come to
fully understand the how McTool UI framework works, particularly where
it connects with the domain.  How would McSaveDialog get access to the
"workingCopy" so I could ask for its changes?  It seems to be a
generic dialog for any pair of Strings, not just McVersions.  I see
it's called via Notification too, probably why sometimes the Ok button
doesn't save the package (and losing my version comments!)...


On Thu, Sep 9, 2010 at 6:31 PM, Chris Muller <asqueaker at gmail.com> wrote:
> Hi all.  I really agree with Bert on this one; MC has a model that
> includes timestamps.  I don't think we should make string copies of
> the model.  The entire ancestor history is already included in memory,
> this would really add quite a bit of bloat to it..
>
> Just so you know, it is not hard, just cumbersome, to check a methods history.
>
> Just look at the last changed date of the method in question, then
> select the "History" button of its package in the Monticello browser.
>
> Scroll down the left-side to the version whose timestamp is just after
> that of the methods timestamp.  Yellow-click and "spawn history".  Now
> you can select the second version in the list and browse the changes
> between those two versions.  Repeat for even more prior versions of
> the method.
>
> I have long been thinking about how nice it would be for some utility
> to enumerate the entire history of a package and build a nice model of
> its history.  Who has the time?
>
>
>
> On Thu, Sep 9, 2010 at 12:08 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>
>>
>> On Thu, Sep 9, 2010 at 9:21 AM, Bert Freudenberg <bert at freudenbergs.de>
>> wrote:
>>>
>>> On 09.09.2010, at 17:58, Andreas Raab wrote:
>>>
>>> > I really like this but I am wondering: Why are the changes only listed
>>> > as a reminder and not kept in the checkin comment? One of the biggest
>>> > difficulties that I often have is finding out where exactly a method got
>>> > modified in the history of some package which is exactly what's provided
>>> > here. It also gives a scope for how sweeping the changes in a particular
>>> > package versions were.
>>> >
>>> > So I vote for leaving the information in the checkin comment.
>>> >
>>> > Cheers,
>>> >  - Andreas
>>>
>>>
>>> Well, that's how other SCM handle it, and where I got the idea from. The
>>> comment should be written and not be generated, I think.
>>>
>>> E.g. when I look at a package's version history on squeaksource, I'd hate
>>> having to see the modified methods all the time. Maybe we need a "-v" button
>>> ;)
>>>
>>> Listing the difference between two versions should really be a separate
>>> operation IMHO and not be part of the comment (where it would also be
>>> unreliable). We lack UI for that, true, but I'd rather wait for that than
>>> cluttering the comments now, which we can't undo later.
>>>
>>> I wouldn't mind storing the modifications as a separate field in
>>> MCVersionInfo as much, although the version history already takes up quite a
>>> chunk of space in an MCZ package. Making it even larger is not a good idea
>>> imho.
>>
>> [I feel like Vizini this a.m.]
>> For me being able to find out in what version a method changed would be very
>> valuable, so like Andreas I would like the changes in the version history.
>> But for me being able to upload and download packages quickly is vey
>> important, so like Bert I would not like the changes in the version history.
>> Since we know that currently the version history does not include method
>> change history we know that adding the info at this stage would not yield
>> benefits for a long time.
>> But if we wrote an offline tool we could collect that version history from
>> existing and future package files and put it in a parallel file to each
>> package file with a different extension to mcz and if that file behaved
>> sufficiently like an mcz then the versions browser could show it.
>> Time to take some Iocane powder.
>> 2¢
>> Eliot
>>>
>>> - Bert -
>>>
>>> > On 9/7/2010 7:29 PM, commits at source.squeak.org wrote:
>>> >> Bert Freudenberg uploaded a new version of Monticello to project The
>>> >> Trunk:
>>> >> http://source.squeak.org/trunk/Monticello-bf.399.mcz
>>> >>
>>> >> ==================== Summary ====================
>>> >>
>>> >> Name: Monticello-bf.399
>>> >> Author: bf
>>> >> Time: 4 September 2010, 7:06:03.314 pm
>>> >> UUID: d34224f4-a77d-44ec-9981-4a9e6fec5d29
>>> >> Ancestors: Monticello-ar.398
>>> >>
>>> >> When saving a package, the changes about to be committed are listed as
>>> >> a reminder.
>>> >>
>>> >
>>>
>>>
>>
>>
>>
>>
>>
>