On Jul 10, 2008, at 21:43, Ben Collins-Sussman wrote:
> This feature has been discussed over and over through the years; if
> you search the dev@ archives, you can read the debates. The opinion
> of the dev team is that this is not a useful feature in general;
> while it might help a very small minority of users that wish to track
> original timestamps, it would create more trouble and complexity for
> the majority, and be hard to maintain. So the lack of this feature is
> a deliberate decision, not an accidental oversight.
>
> The arguments against the feature have basically been:
Hi Ben. I'll repeat some arguments that have been made over and over
for this feature:
> * When no version control is used, then it's clear file timestamps are
> critical. They're the only indication of a file's "version". But
> once the files are placed into version control, what's the point of
> tracking the original datestamps? Version control is now providing
> much more detailed tracking of versions and dates. It's solving the
> problem is a much more thorough way.
When importing an existing project, I consider it important to know
when those files were last modified. I may be importing the project
today, but maybe I developed over a period of months last year. I'd
like that metadata preserved.
It's not Subversion's place to decide that the modification time of a
file is not important. It is important to me, and to many other
Subversion users as well.
> * Version control is typically used for code. Having timestamps
> touched by 'svn update' solves the 90% use-case of causing programs
> like 'make' to rebuild exactly what has changed. This is a useful and
> important default behavior.
Not all code uses make. I don't write compiled software; I write
interpreted scripts in languages like php and bash. Others might be
writing in ruby or python or perl. We do not need makefiles and we do
not need to be bound to the deficiencies of make.
Also, not all repositories contain code. I have a second repository
for musical compositions, for example.
> * For all other cases, the 'use-commit-times=true' option causes
> timestamps to reflect repository mod-times, rather than 'svn up'
> mod-times, thus providing the same sort of simulated
> versioning-via-timestamp for files being exported to people without
> subversion.
"use-commit-times=true" is sufficient for my purposes, after the
initial import of an old project. But for old projects, as mentioned
above, import time is often not even close to modification time.
Also the case has been made that for applications like web site
development, it's important for caching reasons to have the same
modification time on a file (whether that be the original
modification time or the commit time is not important). If you check
out a working copy today and serve it via a web server, it sends out
the (static) files' modification times. If you then check out a new
working copy tomorrow, or use svn switch or something, the
modification time on the files changes, even though the file is the
same. The web server will think the file has changed and will send
out the new modification time which will cause browsers to
unnecessarily redownload the files, wasting time and bandwidth. So
for web site applications, at least at the server side, the default
of "use-commit-times=false" could be considered harmful.
> * If you want to be even friendlier to people without subversion, you
> can put $LastChangedDate$ or $Revision$ keywords directly into the
> files to be expanded.
To be completely pedantic :) it seems like $LastChangedDate$ does not
show the date the file was last changed by the author. It shows the
date the file was last committed. I guess you could say it's the date
the file was last changed in the repository.
> If none of these features satisifes your use-case, I'm curious to hear
> exactly what you're trying to accomplish, and why these solutions
> don't work for you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-11 09:37:55 CEST