svnversion & svn st

[Bill Comisky <bc...@pobox.com>]

I noticed that when I run 'svnversion' and 'svn st' it will take a "long"  
time (~12s on /svn source tree) to execute, and then after the first
execution it will run quickly (< 1s).  Then I noticed this behaviour every
day, even though I hadn't accessed the directory tree in question.  Or
hadn't accessed it directly anyway...  My best guess is a backup script or
updatedb cron job is accessing the directories.

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?

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 ;)

bill

--
Bill Comisky
bcomisky@pobox.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svnversion & svn st

[Bill Comisky <bc...@pobox.com>]

On Fri, 22 Aug 2003, Ben Collins-Sussman wrote:

> Bill Comisky <bc...@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.  :-)

Hadn't thought of the caching as the reason for the speed up.  Especially
since the slowdown seems so regular (overnight).  I was assuming some cron
job was changing my directory access times and making svnversion/svn st do
more work.  As a test I just ran 'hdparm -f' on my filesystem to flush the 
cache, then 'time svnversion .' twice.  

1st run after flush:  2.56s elapsed
2nd run after flush:   .40s elapsed

1st run every morning:  ~10-12s elapsed.

Maybe there is some other caching somewhere I'm missing to make up the 
difference?  Regardless, I think I'll just setup a cron job to run it 
early in the morning!

thanks,
bill

-- 
Bill Comisky
bcomisky@pobox.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svnversion & svn st

[Ben Collins-Sussman <su...@collab.net>]

Bill Comisky <bc...@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