Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed

On Nov 27, 2005, at 19:23, Malcolm Rowe wrote:

> On Wed, Nov 23, 2005 at 07:11:45AM +0100, Ph. Marek wrote:
>
>> What is wanted?
>> - To save the (modification-) timestamp for each committed file, and
>>   to restore them.
>
> It might be useful to include a brief note on why this requirement  
> exists
> in the first place: what need or use case isn't being fulfilled by the
> current functionality?

People on this list are constantly going on about how a version  
control system's job is to accept and archive data thrown at it, not  
to change it. This is presented as an argument against many user  
suggestions—for example, the ability to have a post-commit hook do  
automated syntax formatting on committed source code files. The  
rationale is that the system should not store a modified version of  
what the user commits; it should store exactly what the user commits.  
The same argument should be applied to metadata such as the  
modification date.

Suppose we have a programmer Joe who can't write any decent code  
before 10 AM when he has his second cup of coffee. Suppose he writes  
some code before 10, some other code after 10, and commits everything  
together at 11. The commit time is 11, and when checked out (with use- 
commit-times on) the modification time of the files is also 11.  
Suppose we are looking at the code now and wondering if it is  
correct. If we could see the time at which the files were actually  
modified, we would be better-able to decide which files might be  
suspect.

A less-contrived example would be importing an old project into a new  
repository. All files in the project will allegedly be modified at  
the commit time, when in fact the project may have been last modified  
years. The act of importing the project in effect deletes the history  
of the project, and someone who later looks at the project will think  
it's newer than it is.