RE: Problem with partial check out

                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.teitge_at_ultra-it.de]
Sent: vrijdag 30 maart 2012 23:35
To: users_at_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.kolinko_at_gmail.com]

Gesendet: Sonntag, 25. März 2012 22:37

An: users_at_tortoisesvn.tigris.org

Betreff: Re: Partial Checkout Problem

2012/3/25 Elmar Teitge <elmar.teitge_at_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!
Received on 2012-03-31 10:58:24 CEST