The Trunk: Monticello-bf.399.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

The Trunk: Monticello-bf.399.mcz

commits-2
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!


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Monticello-bf.399.mcz

Andreas.Raab
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:

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

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Monticello-bf.399.mcz

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


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Monticello-bf.399.mcz

Eliot Miranda-2


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.

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





Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Monticello-bf.399.mcz

Casey Ransberger-2
Never get involved in a land war in Asia;)

On Sep 9, 2010, at 10:08 AM, Eliot Miranda <[hidden email]> wrote:



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.

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






Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Monticello-bf.399.mcz

Hannes Hirzel
In reply to this post by Bert Freudenberg
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

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Monticello-bf.399.mcz

Bert Freudenberg

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

> 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?

Yes.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Monticello-bf.399.mcz

Hannes Hirzel
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:31, Hannes Hirzel wrote:
>
>> 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?
>
> Yes.
>
> - Bert -
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Monticello-bf.399.mcz

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


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Monticello-bf.399.mcz

Hannes Hirzel
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 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 -
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Monticello-bf.399.mcz

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

> 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

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 -

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



Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Monticello-bf.399.mcz

Chris Muller-3
In reply to this post by Eliot Miranda-2
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:

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

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Monticello-bf.399.mcz

Chris Muller-3
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:

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

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Monticello-bf.399.mcz

David T. Lewis
In reply to this post by commits-2
On Tue, Sep 07, 2010 at 07:29:02PM +0000, [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.
>

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