[squeak-dev] Re: The Trunk: Monticello-bf.399.mcz

Chris Muller asqueaker at gmail.com
Thu Sep 9 23:31:14 UTC 2010


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



More information about the Squeak-dev mailing list