Subversion Integration and "entries" file access.

I've got a problem with the Subversion integration. The box I'm running on is a dual-core Athlon 64 3800+ with 2Gb or RAM. Our project has a couple of folders that have many files within them - the main culprit having around 1300 files. JavaSVN seems to access the entries file within the .svn folder over and over and over. Each block of accessing lasts for around 4 minutes and for that 4 minutes, one of my processors is pegged at 100%. Sysinternals Process Explorer shows that the entries file is being constantly opened and closed during this process. Has anybody else seen this behaviour?

I've found that if I perform an SVN Cleanup on the project, the problem goes away, but only for a short while and then starts all over again. I suspect it is doing what it needs to do, but perhaps not as efficiently as it could.

I'm using IntelliJ 5.1 Build 4155. OS in Windows XP SP2. The Subversion repository is running on a remote linux box running Red Hat Enterprise (don't recall the version) and running against Subversion 1.2.3 (although, the same behaviour occurred under earlier versions of Subversion).

Cheers
Tony

10 comments

Forgot to add - While this accessing is going on, I get errors when trying to update the project. The error is typically:

Error: svn: Cannot rename file '...\.svn\tmp\entries'

0

Hi Tony

I got rid of the problem related to
Error: svn: Cannot rename file '...\.svn\tmp\entries'
after disabling Google Desktop Search.

Maybe this is of any help to you...

etienne

0

Hi etienne,

I don't have Google Destop Search installed. I use Copernic instead. I'll give it a try. Thanks for your reply.

Tony

0

Hi etienne,

Disabling my Desktop Search utility does not semm to have made a difference. Thanks for the tip though.

Tony

0

Some users report that upgrading javasvn.jar to 1.0.3 fixes performance problems with SVN integration. 1.0.3 beta JavaSVN is bundled with IDEA.

You can try replacing IDEA_HOME\plugins\svn4idea\lib\javasvn.jar with javasvn.jar from this distribution: http://tmate.org/svn/org.tmatesoft.svn_1.0.3.standalone.zip

However, according to reports, this fixes different issue descibed below:

Committing changes to a Subversion repository with IntelliJ 5.1 is
really slow. The machine just seems to idle for a while before
completing the commit. Checkouts are fine, it's just the commit that is
slow. It doesn't matter whether we use http or https to access the
repository, whether the repository is on the local machine or on the
network, or whether we use Windows or Linux.

0

Hi Serge,

I'm actually using a version of javasvn that I've built locally from the latest release. I'm seeing the same behaviour in this version as in the version that ships with 5.1. I've attached a screen grab from process explorer that shows what's going on. Note the CPU history graph at the top right, as well as the file access in the bottom pane.

Tony



Attachment(s):
Subversion polling.jpg
0

Some applications may conflict with JavaSVN library and IDEA as was stated above.

Also there are known problem with TortoiseSVN client, it's scanning/locking directories. Antiviral monitors may also cause it. Recently I had weird issue with slow file access, I had Symantec Anitivirus installed (but it was disabled). Even in disabled state its driver caused a lot of issues. Uninstalling Symantec Antivirus completely fixed the problem for me.

I recommend you rebooting, disabling/uninstalling all such applications (that watch/scan files) and try again.

Process Explorer allows to view drivers that affect application.

0

As suggested, I've uninstalled TortoiseSVN. We don't use Symantic Antivirus here, we use Trend Office Scan, although, this is a corporate thing that I cannot uninstall. As an aside, I also found that file indexing was on in my drive properties. I've disabled that as well. The problem persists, however it only pegs the processor for about two minutes now. Is there a way to dump the stack and determine what is going on from that?

Tony

0

The problem doesn't seem to be happening at the moment. Perhaps uninstalling TortoiseSVN has done the trick. If it happens again, I'll take the CPU snapshot and add it as suggested.

Tony

0

Please sign in to leave a comment.