Sorry to respond to my own message, had to clear my first issue up
The entire tree does NOT indeed show as modified, but subversion seems
to attempt to diff every file in the tree to tell if it's just a
timestamp change, or the file is actually modified.
It was only apparent to me when my other issue with the $Id:$ diffing
I'd check out a tree using 'use-commit-times' and the files which
contained '$Id:$' in them showed up as modified even though I didn't
actually change it. So it was apparent that subversion noticed the
time stamp difference between last update and actual file time stamp.
In a regular tree (converted from cvs), this issue doesn't appear, even
if I 'touch' a file then do status again. I assume though that svn is
performing a text diff on the files with the suspect timestamp to see
if I indeed changed them.
So, using 'use-commit-times' on a tree with say, 200 files, results in
a 'svn status' command taking several seconds while it performs the
I'm just suggesting that svn stores (somewhere in .svn I'd assume), the
repo timestamp of each file so it doesn't spend it's time performing a
diff of the entire tree. (my main tree, which has not been converted
yet due to cvs2svn errors, is 20k+ files, that would seriously hurt to
On Mar 17, 2004, at 1:04 PM, David Budworth wrote:
> Sorry, didn't make the actual issue clear really
> There are two issues:
> 1) When using 'use-commit-times' in your global config, the files are
> indeed stamped with the commit time, but 'svn'(client) seems to not
> track what the original commit time of the WC files are.
> This results in all 'svn status' invocations to perform a diff
> between the WC and the original version. In effect, subversion
> thinks I've done the equivilent of 'touch' on all my files, and shows
> the entire tree as 'Modified' immediately after a check out.
--- snipped my own over-verbosity ---
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Mar 17 22:22:39 2004