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
lesmikesell_at_gmail.com
---------------------------------------------------------------------
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