Hi Marcel,

On Oct 17, 2015, at 10:47 AM, commits@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)