title: svn update slow (15+ minutes on a 1Mb repository)
body: <p>Running <code>svn update</code> on our live server sometimes takes more than 15 minutes to complete.</p>
  
  <ol>
  <li>Our repository is very small, around 1Mb with ~100 files (it's a small website)</li>
  <li>We have a couple of developers that do both commit/update and this is working very good</li>
  <li>We update all changes on our server (which only does <code>svn update</code>) and this is running painfully slow</li>
  <li>We have never done a <code>svn commit</code> from the server (it's supposed to be a read-only version of our site)</li>
  </ol>
  
  <p>As time goes by it seems to get slower and slower to do <code>svn update</code> on the server, even if it's just one file that needs to be updated. I'm starting to think that the "age" of the repository on our server has to do with how slow it is? If so, is there anything we can do to speed it up?</p>
  
  <p>UPDATE #1</p>
  
  <p>I still think the "age" has something to do with <code>svn update</code> being slow, but might have to consider what is actually happening when the repository "age" on the server...</p>
  
  <p>The reason I think this is the following:</p>
  
  <ol>
  <li>We have checked out the repository on WebsiteA (using <code>svn checkout</code>) and updated it on regular intervals (using <code>svn update</code>) since January 2010</li>
  <li>We have also checked out the same repository on WebsiteZ the same way, but this happened just a few days ago ie July 2012</li>
  <li>Both WebsiteA and WebsiteZ are on the same physical server and both are using the same repository</li>
  <li>Running <code>svn update</code> on WebsiteA to update from revision 100 to 101 takes 20+ minutes</li>
  <li>Running <code>svn update</code> on WebsiteZ to update from revision 100 to 101 takes just a few seconds</li>
  </ol>
  
  <p>The only difference between these websites that I can see is that WebsiteA has existed a bit longer. WebsiteA may have a few extra files in it (cached content), though this is very minimal (less than 20 files) and the directories that contain the cache files have been set to ignore all files using svn:ignore.</p>
  
  <p>I guess I couldn't rule out network issues, but I assume that WebsiteA and WebsiteZ would run the same firewall settings and if there was a rule it would be a "block" rather than "delay". Since both websites are on the same server I assume they should both update in the same amount of time in terms of network issues.</p>
  
  <p>UPDATE #2</p>
  
  <p>It might be worth noting that if we do <code>svn update file.txt</code> it runs very fast. It's as if svn is comparing everything we have in the directory, just to figure out what to update.</p>
  
  <p>UPDATE #3</p>
  
  <p>We ended up upgrading svn and upgrading all checked out revisions. <code>svn update</code> seems to run a lot faster now and fingers crossed it stays that way. Thank you everyone for helping!!</p>
  
  <p>UPDATE #4</p>
  
  <p>Sure, doing a fresh checkout solved the problem, but only for a few days/weeks. I think finally today we found the cause of svn being slow. We're using Zend_Auth and call Zend_Auth::hasIdentity() on every page to check if users are logged in. This call creates a session, which in turn creates a session file on the server. If the browser (or googlebot) is browsing with cookies turned off we create one session file for every single request. Hence our session directory had millions of files. We deleted the files in the directory and fixed the way we determine if the user is logged in by checking if the cookie has been set before calling hasIdentity(). <code>svn</code> updates now run at &lt;30 seconds.</p>