Hi,
Are you sure you checked out the right directory from boost. I performed a $ svn co http://svn.boost.org/svn/boost/trunk boost (as recommended on http://www.boost.org/users/download/#repository) on my 2 year old notebook without solid state disk. (Just a simple 7200rpm 2.5 drive) And I got a working copy with just a 29 MB .svn/wc.db The working coy contains 37383 nodes And 33537 pristine files. An fully recursive svn update from the root of this working copy takes about 2.5 seconds on the working copy. (A bit more if updates come in) Probably with a hot filesystem cache, but stil... My guess is that you accidentally checked out the root of the repository instead of just trunk. You should never do that unless you really understand what you are doing. (That would check out all files in all different variants, etc.) The only this item update performs a single operation with network initiation for every selected item. Usually that is orders of magnitude slower than performing a recursive operation on the root. (Subversion is fully optimized for recursive operations; not for single item operations) Bert From: Elmar Teitge [mailto:elmar.tei...@ultra-it.de] Sent: vrijdag 30 maart 2012 23:35 To: users@subversion.apache.org Subject: Problem with partial check out Hello, I have a problem with partial checkout of the repository from the boost c++ library. First I guessed, that this is a problem with Tortoise SVN, because there have been problems with the TSVN cache in the past. Switching off the caching mechanism showed, that this is not the cause of the problem. The total discussion with the TSVN developers is attached below. Deleting the whole content of a folder from the working copy by doing an update to revision with option only this item is running over 30 hours and there is absolutely no measurably progress with a solid state disk. Doing an clean-up process takes only about an hour. Is this an known issue can anyone help with this topic ??? Thanks. Best regards, Elmar ---------------- Hello Elmar, What you mean by a bug? That database access when database is stored on a solid state drive is slow? I would say it is not a bug, it is physics. In essence I would say that there are many small transactions and each updates the database, and writes are slow. If you want to dig further 1) look for SQLite knowledge. There are some subtle ways how the database can be tuned. It is some specific subject and I cannot help you with it. 2) look at the mailing lists at subversion.apache.org and their archives . Performance of working copy operations is sometimes discussed there. Though usually people are faced with it when trying to work over network (e.g. client running on Windows accessing wc stored on a network drive somewhere). That is one more scenario where performance is known to be poor. 3) the database size of 500 Mb is bad. You have too many single files to manage. :/ As I mentioned, svn cleanup would not shrink it. There exist some sqlite commands that can claim unused space in a database file, but you would need an sql client to execute them, not svn client. Best regards, Konstantin Kolinko ---------------- Hello Konstantin, thanks for your response. I have done a new trial for checking out the repository ... Two folders were checked out, the branches and the sandbox folder ... I I tried again dumping the content of the sandbox folders by "update to revision" with option "only this item" ... that was running about 5 hours, than I cancelled this process in the update dialog ... I had a look in the .svn folder and found out, that the SQLite database file was 570 MB in size ! So I decided to do an experiment and deleted all pristine content and all the files in the working copy folders ... in the next step I have done the clean-up process like you described it ... After the clean-up process, the database file is still 570 MB large ... ... and an update process with "only this item" is still in progress with no result ... I am sure, that my problem is caused by a bug. But how to do a trace, that helps to find that bug ? Best regards, Elmar -----Ursprüngliche Nachricht----- Von: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Gesendet: Sonntag, 25. März 2012 22:37 An: us...@tortoisesvn.tigris.org Betreff: Re: Partial Checkout Problem 2012/3/25 Elmar Teitge <elmar.tei...@ultra-it.de>: > Hello Konstantin, > > thank you for your advice. > > To point 1, I have selected the folder that shall be cleared from > subfolders, called "sandbox" and then selected "update to revision" in the > context menu with selected option "only this item". > > To point 2, I have done a few cycles doing the update in point 1 and > doing > an clean-up command on the whole working copy ... but the SQLite > database > file did not shrink perceivable, nor the additional folders in the pristine > directory, that keep the original files ... > > Is it enough, to clean-up the svn status or are more options required > in the > clean-up dialog, to get rid of the unused pristine files ? > - The first checkbox there is enough (that is what "svn cleanup" command-line command does) plus the last one (to apply cleanup to the nested WCs that belong to externals). The other checkboxes there are specific to TortoiseSVN. - The unneeded files are deleted from "pristine" directory. Well, if you have 5 identical branches then there will be the same 1 pristine for 5 copies of a file in branches, so maybe that is why there were no substantial changes. - The db file does not shrink. It should not be of big size though. (It is possible to shrink it with some "sqlite pragma" command -- I have seen it once being mentioned on @subversion mailing lists). > To point 3, there were no modifications on that sandbox folder. > Best regards, Konstantin Kolinko ---------------- Hello Konstantin, thank you for your advice. To point 1, I have selected the folder that shall be cleared from subfolders, called "sandbox" and then selected "update to revision" in the context menu with selected option "only this item". To point 2, I have done a few cycles doing the update in point 1 and doing an clean-up command on the whole working copy ... but the SQLite database file did not shrink perceivable, nor the additional folders in the pristine directory, that keep the original files ... Is it enough, to clean-up the svn status or are more options required in the clean-up dialog, to get rid of the unused pristine files ? To point 3, there were no modifications on that sandbox folder. Best regards, Elmar ---------------- Hello Elmar, 1. Maybe you selected wrong folder when invoking the update operation? 2. Note, that "svn update --set-depth" will remove the files and folders from your working copy, but pristine copies of the files will be still present on your drive. You have to do "svn cleanup" to get rid of unused pristine copies. (This is a known unimplemented feature and is mentioned in Subversion 1.7 release notes). 3. If there are modified files, ignored files, or files that it cannot delete then Tortoise just plays safe and leaves them on your hard drive. It deletes only files that are controlled by subversion and have no modifications. Use "Check for modifications" dialog to see what is the state of your working copy. Best regards, Konstantin Kolinko ---------------- Hello TSVN users, I have tried to check out the boost c++ library repository as a working copy on my local Solid-State-Disk. I experienced, that the boost repository is too large for that check out I want to do. So I decided to make a partial check out with dumping the sandbox items for my working copy. About 60 % of the working copy were created on the disk and I tried to dump the sandbox folder by doing an svn update command with the option "only for this item" to delete all subfolders for that directory. The TSVN update dialog was running over 30 hours and only one subfolder was deleted from the sandbox directory. I am using the current TSVN Version 1.7.6. I am not sure if this is a conflict with the TSVNCache, or if this is a problem with subversion itself. Has anyone made experiences with that topic and is able to help me ? Thanks. Elmar _____ I am using the Free version of SPAMfighter <http://www.spamfighter.com/len> . SPAMfighter has removed 51 of my spam emails to date. Do you have a slow PC? <http://www.spamfighter.com/SLOW-PCfighter?cid=sigen> Try free scan!
