Re: svnversion & svn st

Bill Comisky <bcomisky@pobox.com> writes:

> I noticed that when I run 'svnversion' and 'svn st' it will take a "long"
> time (~12s on /svn source tree) to execute,

Yes. Every single working file in your working copy needs to be stat()ted.

> and then after the first execution it will run quickly (< 1s).

And now your OS disk-caching kicks in. :-)

> I just did a 'find . -ctime -2', 'find . -mtime -2', and 'find -atime -2'
> at the root of the tree. ctime (status last changed) and mtime (last
> modified) showed nothing for the last 2 days. atime (last accessed)
> showed all of the contents of the .svn subdirectories and all of the
> directories. I did just run 'svn st', so that makes sense. So what do
> 'svnversion' and 'svn st' use as an indicator to recheck the directory
> contents?

I'm not sure I understand your question. Subversion uses an algorithm
similar to CVS to determine if a file has been modified or not:

   * if the timestamp hasn't changed ==> no change
   * else if filesize of working & base files aren't equal ==> changed
   * else, do a byte-for-byte comparison

> This is probably a non-issue for most, but I call svnversion from my
> (non-compiled) code to get the revision # for my single-revision working
> copy. So the first time I do that every day I have to wait an agonizing
> >10s (which is an hour a year I'd rather do something else with ;)

svnversion is basically doing the same thing, but on directories: it
loads up the .svn/entries file of every single directory in order to
"collate" all the working revisions.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 22 16:08:14 2003