On Fri, Jul 11, 2008 at 2:37 AM, Ryan Schmidt
<subversion-2008c_at_ryandesign.com> wrote:
>> * 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.
I think you're right: even if Subversion doesn't make any use of the
file's original mod-time, it could at least be saved in a property so
the information isn't lost completely.
>
>
>> * 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.
Uh, but does the default behavior (of being kind to compiled
languages) actually have any negative affect on interpreted languages?
I can't see any, so this seems like a good default behavior to me.
>
> Also, not all repositories contain code. I have a second repository for
> musical compositions, for example.
Me too. :-)
>
>
>> * 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.
>
Yep, and I would recommend that people using svn to manage websites
turn on use-commit-times=true. That's one of the main use-cases for
that feature.
That said, I'm willing to wager that across the board, svn is used
much more often to manage code than websites, hence the default of
use-commit-times=false.
>
>> * 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.
Yes, that's exactly what it expands to. The philosophy is that once
objects become version controlled, the only "true" timestamps which
matter are the ones the repository, since the repository is tracking
all changes. Working copies are but shadows on the wall, which can
optionally be made to reflect repository timestamps.
---------------------------------------------------------------------
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 16:18:25 CEST