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

Re: import files preserving timestamps

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: Sat, 07 Jun 2008 12:08:53 -0500

Erik Huelsmann wrote:
> In a previous mail you suggested there are no arguments *not* to
> include versioning of timestamps in your vc system (i believe), but I
> think there are plenty, which is exactly why it hasn't been done. It's
> a hairy topic:
> - Do you also commit a file if the timestamp changes? Some say 'of
> course', others say 'never'
> With which I mean: the feature isn't all that clearly defined and in
> fact may be a request for many different features (supporting many
> different use-cases).
> - It complicates the code in your VC system.
> Complexity is the enemy of stability. You should want the latter to be
> the top priority of your VC.
> - Time spent on developing this feature will reduce time spent on others
> I think Subversion has enough feature requests outstanding which are
> generally considered 'more important' than versioning of timestamps.

As a counter argument, there are times when timestamps matter even if
they aren't absolutely critical. Consider a busy web server farm with
its code managed in subversion. All of the images, css, js, etc. can be
set to be cached on the clients until they change, but if the timestamps
can't be maintained to correspond to actual modifications you'll waste a
large amount of time and bandwidth resending them unnecessarily and it
becomes much harder to build optimizations like combining multiple
js/css files for efficiency if you can't track their modification times.

   Les Mikesell
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-07 19:09:26 CEST

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

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