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

RE: Re: Keeping last-modified dates

From: Steve Fairhead <steve_at_fivetrees.com>
Date: 2006-08-29 17:01:08 CEST

Ian Brockbank said:

>> Conversely, if I'm trying to investigate a problem in an old version, I
need to be able to roll back and play around with the old code. With
subversion's current timestamp behaviour, I just need to update to the
correct version and rebuild. If the timestamps were set to the check-in
time or similar, Visual Studio would see that they were older than the
object files and skip over them. I have wasted hours in the past trying to
work out why my code wasn't doing what I expected only to find the code
hadn't been rebuilt. Yes, in some ways trivial, but under pressure it's the
simple things you miss. <<

When doing a rollback, or anything other than what the makefile system is
designed to deal with, it's always prudent to do a "make clean" (or its
equivalent, or a "touch" of the affected file[s]) - regardless of what VCS
you're using, or indeed not using. T'was ever thus.

>> That's the issue subversion's current behaviour avoids. Fine, get it
added as an option, but please don't force me to use it. <<

Forgive me, but you appear to be blaming the tools for what amounts to a
user error. I know the error (been there ;)), but once bitten...

In any case, it's becoming abundantly clear that "preserve original
timestamp" should be a checkout option. As someone else has noted, consider
the Unix "cp -p" precedent.

Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 29 17:38:39 2006

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.