Thursday, January 10, 2008

Deadly Combination: Eclipse + Subversion for .NET

In our development team, there are 2 PCs that is running significantly slower than others. It's been bothering me quite some times. They just answered that this machines from the remote office are slower. I just didn't buy that.
Waiting for these PCs to perform simple things in Eclipse almost turn me belly up...

It seems like it comes from the same models as the one I'm using! And for me, mine, this is the fastest development machine I could ever have in my life. P4 dual core, 3GHz. Everything you need to develop comfortably using WebLogic Server 10 and Eclipse 3.3 Europa!

I've been tracing through processes, and looking for traces of worms, viruses, or probably something else running in the background. I checked whether they update the Windows security patches quite often, I also ask whether they updated their antivirus data regularly. Everything seemed to be ok.

Later when I opened Eclipse, I noticed that there are so many "_svn" folders showing up in the project. This is a sign of Subversion hack for .NET platform. Normally Subversion will store its information in a ".svn" folder. But the Visual Studio .NET has the problem reading files containing "."s. So the workaround is to set the TortoiseSVN to use "_svn" instead of ".svn".

Instead of ignoring the files (or interpreting the content of the folderwhen you have any of the Subversion plugins of Eclipse), Eclipse tried to parse the folders and put it in its project directory structure. As Eclipse run this process in the background, trying to parse information from Subversion's binaries data, this brought Eclipse performance down to knee.

After asking them to use .svn/** version of Subversion, the performance problem

There might be some solution to this, like place the _svn/** folder under ignore file list so that Eclipse could be told not to parse the binaries file inside _svn/**.