On Monday 27 Sep 2010, Niklas Deutschmann wrote: > The performance of Subversion when checking out large number of files in > a single directory becomes extremely poor when the svn:mime-type > property is set to some binary MIME type. > > Steps to reproduce: > > 1. Create a project that contains a few thousand small files in a single > directory that have no svn:mime-type property set. > > 2. Check out project > > 3. Set svn:mime-type property to some MIME type that indicates a binary > file (application/xyz) and commit > > 4. Check out project > > The second checkout takes *dramatically* longer. Some numbers (project > with 3500 files, each ~1KB) > > - no MIME type: ~2 minutes > - "binary" MIME type: >10 minutes (79% after 10 minutes, getting slower > and slower for each file) > > We are using Subversion 1.6.6. The problem occurs > - with the command line client > - with the Subclipse Eclipse plugin (Eclipse 3.6) when the JavaHL client > library is used. > - with both the svn:// and the http:// protocol > > The problem does *not* occur with Subclipse and the svnkit library > > Niklas
I'm currently trying to reproduce this as I'm interested in this type of problem but I'm having difficulty with svn 1.6 and am time constrained so will give it another shot later. Not really helpful and more discussion than anything but it sounds a lot like a common performance gotcha that appears when abnormal conditions are met such as this. Somewhere there is a list that is being linearly searched and added to as each entry of the directory is checked out. The problem is, it might turn out the solution to that slows down the typical case too much. -- __________________________________________________________________________________ Sword Ciboodle is the trading name of ciboodle Limited (a company registered in Scotland with registered number SC143434 and whose registered office is at India of Inchinnan, Renfrewshire, UK, PA4 9LH) which is part of the Sword Group of companies. This email (and any attachments) is intended for the named recipient(s) and is private and confidential. If it is not for you, please inform us and then delete it. If you are not the intended recipient(s), the use, disclosure, copying or distribution of any information contained within this email is prohibited. Messages to and from us may be monitored. If the content is not about the business of the Sword Group then the message is neither from nor sanctioned by us. Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this email or any attachment. __________________________________________________________________________________
