Hi Marcel,

> On Oct 17, 2015, at 10:47 AM, commits at source.squeak.org wrote:
> 
> Marcel Taeumel uploaded a new version of System to project The Trunk:
> http://source.squeak.org/trunk/System-mt.771.mcz
> 
> ==================== Summary ====================
> 
> Name: System-mt.771
> Author: mt
> Time: 17 October 2015, 6:38:55.72 pm
> UUID: 4aee8d76-cfcf-ad48-ae3e-6d971ce6fea9
> Ancestors: System-cmm.770
> 
> Log change stamps at the granularity of seconds not only minutes.
> 
> Why? A minute is quite long and it is likely to have two method (versions) with the same timestamp.

I think we should discuss this a bit further. This is all a soft touchy freely gut kind of thing for me: I don't like this change.

I think the granularity for time stamps needs to differentiate versions in different package commits.  Within an image versions can be distinguished by their order in the changes file (the previous source position, can't remember what that's called and I'm on my phone). So there's no real need for fine granularity.  One could also say that a second is a long time if one is auto generating methods.

I quite like being able to make several changes within the same minute because I can tell that they were related changes.  With second granularity I have no chance.

Do you have a programmatic reason for wanting second granularity?

What to others think? Are there workflow implications to the granularity of time stamps?  This is all very anal but, well, the changes file is all very anal anyway :-)

I 


_,,,^..^,,,_ (phone)