The Trunk: Monticello-bf.399.mcz

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.

=============== Diff against Monticello-ar.398 ===============

Item was changed:
  ----- Method: MCVersionNameAndMessageRequest>>defaultAction (in category 'as yet unclassified') -----
  defaultAction
  ^ MCSaveVersionDialog new
  versionName: suggestion;
+ logMessage: initialMessage;
  showModally!

Item was added:
+ ----- Method: MCPatchMessage>>modifyDefinition:to: (in category 'patch operations') -----
+ modifyDefinition: oldDefinition to: newDefinition
+ stream nextPutAll: 'M'; tab; nextPutAll: newDefinition summary; cr!

Item was added:
+ ----- Method: MCWorkingCopy>>patchMessageChangesHeader (in category 'operations') -----
+ patchMessageChangesHeader
+ ^ancestry summary, String cr,
+ 'Added, Modified, Deleted',
+ (self ancestors ifEmpty: [''] ifNotEmpty: [' vs. ', self ancestors first name]), ':'!

Item was added:
+ ----- Method: MCWorkingCopy>>patchMessageSuggestion (in category 'operations') -----
+ patchMessageSuggestion
+ ^ self patchMessageDefault, String cr, String cr,
+ self patchMessageChangesDelimiter, String cr,
+ self patchMessageChangesHeader, String cr,
+ self patchMessageChanges!

Item was added:
+ ----- Method: MCWorkingCopy>>patchMessageChanges (in category 'operations') -----
+ patchMessageChanges
+ | changes parentInfo parentSnapshot |
+ parentInfo := self ancestors
+ ifEmpty: [nil]
+ ifNotEmpty: [self ancestors first].
+ parentSnapshot := self findSnapshotWithVersionInfo: parentInfo.
+ changes := package snapshot patchRelativeToBase: parentSnapshot.
+ ^ (MCPatchMessage new patch: changes) message!

Item was changed:
  ----- Method: MCWorkingCopy>>newVersion (in category 'operations') -----
  newVersion
+ ^ (self requestVersionNameAndMessageWithSuggestion: self uniqueVersionName
+ initialMessage: self patchMessageSuggestion) ifNotNil:
+ [:pair |
+ self newVersionWithName: pair first
+ message: (self patchMessageStripped: pair last)].
- ^ (self requestVersionNameAndMessageWithSuggestion: self uniqueVersionName) ifNotNil:
- [:pair |
- self newVersionWithName: pair first message: pair last].
  !

Item was added:
+ ----- Method: MCPatchMessage>>message (in category 'accessing') -----
+ message
+ ^stream contents
+ !

Item was added:
+ ----- Method: MCVersionNameAndMessageRequest>>initialMessage (in category 'as yet unclassified') -----
+ initialMessage
+ ^ initialMessage!

Item was added:
+ ----- Method: MCPatchMessage>>addDefinition: (in category 'patch operations') -----
+ addDefinition: aDefinition
+ stream nextPutAll: 'A'; tab; nextPutAll: aDefinition summary; cr!

Item was added:
+ ----- Method: MCWorkingCopy>>requestVersionNameAndMessageWithSuggestion:initialMessage: (in category 'private') -----
+ requestVersionNameAndMessageWithSuggestion: nameString initialMessage: msgString
+ ^ (MCVersionNameAndMessageRequest new
+ suggestedName: nameString;
+ initialMessage: msgString
+ ) signal!

Item was added:
+ ----- Method: MCPatchMessage>>removeDefinition: (in category 'patch operations') -----
+ removeDefinition: aDefinition
+ stream nextPutAll: 'D'; tab; nextPutAll: aDefinition summary; cr!

Item was added:
+ ----- Method: MCWorkingCopy>>patchMessageDefault (in category 'operations') -----
+ patchMessageDefault
+ ^ 'empty log message'!

Item was added:
+ Object subclass: #MCPatchMessage
+ instanceVariableNames: 'stream'
+ classVariableNames: ''
+ poolDictionaries: ''
+ category: 'Monticello-Versioning'!

Item was added:
+ ----- Method: MCWorkingCopy>>patchMessageChangesDelimiter (in category 'operations') -----
+ patchMessageChangesDelimiter
+ ^'=== text below is ignored ==='!

Item was changed:
  Notification subclass: #MCVersionNameAndMessageRequest
+ instanceVariableNames: 'suggestion initialMessage'
- instanceVariableNames: 'suggestion'
  classVariableNames: ''
  poolDictionaries: ''
  category: 'Monticello-Versioning'!

Item was added:
+ ----- Method: MCPatchMessage>>patch: (in category 'accessing') -----
+ patch: aPatch
+ stream ifNil: [stream := WriteStream on: (String new: 100)].
+ aPatch operations asSortedCollection
+ do: [:op | op applyTo: self]!

Item was added:
+ ----- Method: MCVersionNameAndMessageRequest>>initialMessage: (in category 'as yet unclassified') -----
+ initialMessage: aString
+ initialMessage := aString!

Item was added:
+ ----- Method: MCWorkingCopy>>patchMessageStripped: (in category 'operations') -----
+ patchMessageStripped: aString
+ | pos |
+ pos := aString findString: self patchMessageChangesDelimiter.
+ ^ (pos > 0
+ ifTrue: [aString first: pos - 1]
+ ifFalse: [aString]) withBlanksTrimmed!

Item was removed:
- ----- Method: MCWorkingCopy>>requestVersionNameAndMessageWithSuggestion: (in category 'private') -----
- requestVersionNameAndMessageWithSuggestion: aString
- ^ (MCVersionNameAndMessageRequest new suggestedName: aString) signal!

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

On 9/7/2010 7:29 PM, [hidden email] 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.

- Bert -

On Thu, Sep 9, 2010 at 9:21 AM, Bert Freudenberg <[hidden email]> 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, [hidden email] 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.
>>
>

On 9/9/10, Bert Freudenberg <[hidden email]> wrote:
> On 09.09.2010, at 17:58, Andreas Raab wrote:


> 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.
>
> - Bert -

A question to understand the issue better:
Does every MCZ package file include the full version history, i.e. all
the comments when commiting?

--Hannes

On 09.09.2010, at 21:31, Hannes Hirzel wrote:

Yes.

- Bert -

OK, this is exciting.

Can we extract this information showhow to produce a full report of
the version history in one window?

A rhetorical question I know because the answer will be 'yes'.

The question is rather how can it be done?

And in the meantime I have actually learned enough about Monticello
that I could probably do it myself.

On the other side if somebody has a script ready hanging around in a
Workspace, may I kindly ask you to post it here.

In the end it will up somewhere in the documentation :-)

--Hannes

On 9/9/10, Bert Freudenberg <[hidden email]> wrote:

On 09.09.2010, at 21:52, Hannes Hirzel wrote:

> OK, this is exciting.
>
> Can we extract this information showhow to produce a full report of
> the version history in one window?

Select a package, click the history button.

Or on source.squeak.org, select a package and click "Show History".

- Bert -

Yes, but what I get in both cases is a browser with the different
versions in the left pane and in the right pane the comment to just
that _single particular_ version.

I d' like to have a window where I see all the comments _combined_.
E.g. in the browser 'Package List'.

Actually a traversal and collection of all the 'message' calls through
the ancestry of the package.

That's my question. And primarily _in_ the image.

--Hannes

On 9/9/10, Bert Freudenberg <[hidden email]> wrote:

On 09.09.2010, at 22:47, Hannes Hirzel wrote:

That's precisely what squeaksource does. Try it. And the code is in the "ss" repository.

It also exhibits the major problem with a linear display - version history is not linear, merges throw it off.

- Bert -

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 <[hidden email]> wrote:

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 <[hidden email]> wrote:

On Tue, Sep 07, 2010 at 07:29:02PM +0000, [hidden email] wrote:
Bert,

I just tried this with a post to inbox, and I like it a lot just as you
have done it here. There's just enough of a reminder to warn me when I'm
about to make a mistake, but it leaves it up to me to decide what to put
in the change comment.

Dave