[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Ryan Schmidt <subversion-2005_at_ryandesign.com>
Date: 2005-11-27 21:03:15 CET

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

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.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 27 21:56:42 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.