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

Re: Poor performance in windows. Switching back to CVS

From: Jeff Smith <jsmith_at_robotronics.com>
Date: 2007-02-14 22:28:42 CET

On Wednesday 14 February 2007 11:46, Les Mikesell wrote:
> The problem is not likely to be something that makes a modification
> without changing the timestamp but rather the opposite: something
> that tries to preserve what it thinks is the correct timestamp

so... is there a difference between "not changing the timestamp" or
"preserve" what should be the correct timestamp? Just fooling with
your choice of words. As far as I see, "something that makes a
modification without changing the timestamp" would only do it for the
reason that it thinks that is the correct timestamp. And yes, those
tools are a threat.

Otherwise you are not saying anything different than me, so I agree.

> while moving the content around - zip, tar, and an assortment of
> other ways of copying files will do that. But consider what
> happens if you zip a copy of something, change/commit the original,
> then unzip your old copy back to undo a mistake. It's now a change
> as far as svn is concerned but the file has an old timestamp.

I'm puzzled whether you are trying to disagree or what.

Certainly if you replace a file from a zip then you are replacing with
an older version, so it makes sense the date is older. Subversion
only uses the timestamp to detect if the file might have changed, and
in the case of restoring an old version from zip, it likely has. So
what's your point? Someone said it detects the older timestamp as
being a change (no reason not to), therefore no problem.

> Or,
> you might copy some files out to work on a different machine where
> the clock setting is wrong, than copy back with a method that
> preserves that wrong timestamp.

Not even the same thing--Subversion does not need to compare
timestamps with the repository, only with the local "pristine copy".
This talk of moving the working copy to another system is risky, and
outside the scope of subversion.

Suggestion: Don't set time different on *any* two relative machines
(what would even be the purpose), esp. if you plan to use version
control between the two.

The big problem is inconsistency when keeping track of time. The only
solution really is to stay consistent. Anything else is only a
workaround.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 14 22:29:32 2007

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.