Selena Build 7905

Hi Jetbrains --

First off thanks for Subversion 1.5 support! That's great.

I just wanted to let you know I'm submitting quite a few exceptions running
this new build that have all started happening in this latest build. Should
I keep submitting to exception analyzer or do you want me to create specific
JIRAs for each exception?

Thanks!

15 comments
Comment actions Permalink

I get a lot of "Please wait until VCS synchronization is finished" that take a very very long time... and soaking a lot of CPU.

I'm still using SVN 1.4. If I accept to update my working copies to SVN 1.5 format, will it speed things up? Is it backward compatible?

0
Comment actions Permalink

I tried it 2 ways :)

One project is 1.4 working copy and then I tried converting another to 1.5.
The initial conversion took a while and a lot of CPU but either case seemed
to work OK.

Most of the exceptions I've had were around editing spring xml files that
had AOP exression langauge in them or even just random programming I'd get
IntelliJ Core exceptions. I keep submitting away so hopefully that's enough
:)

-Grant


"nodje" <no_reply@jetbrains.com> wrote in message
news:33417444.103171215668034397.JavaMail.jive@app4.labs.intellij.net...
>I get a lot of "Please wait until VCS synchronization is finished" that
>take a very very long time... and soaking a lot of CPU.
>

I'm still using SVN 1.4. If I accept to update my working copies to SVN
1.5 format, will it speed things up? Is it backward compatible?


0
Comment actions Permalink

7905 takes ages to do an update (the computing post-update task to be precise).
Even after upgrading to 1.5 format.

Overall CPU usage stays high most of the time. I'm wondering if this alone could explain SVN operation slowlyness.

Command line SVN works as usual.

when trying back with 7878, updated to 1.5 project are not supported but behavior with 1.4 sources is just normal. And overall, no abnormal CPU usage.

I'm on OSX 10.5.4.
Am I the only once to get these problems?

-nodje

0
Comment actions Permalink

Hello nodje,

As usual, please take a CPU snapshot and file a JIRA issue with the snapshot
attached.

7905 takes ages to do an update (the computing post-update task to be
precise). Even after upgrading to 1.5 format.

Overall CPU usage stays high most of the time. I'm wondering if this
alone could explain SVN operation slowlyness.

Command line SVN works as usual.

when trying back with 7878, updated to 1.5 project are not supported
but behavior with 1.4 sources is just normal. And overall, no abnormal
CPU usage.

I'm on OSX 10.5.4.
Am I the only once to get these problems?
-nodje

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

hum, unfortunately neither #7878 nor #7905 would start with the option -agentlib:yjpagent.

I've tried different memory option but to no avail, it always crashes instantly.

The only thing I can do right now is post the OS X error report but I don't know if it's going to provide much help since it describes a JavaApplicationLauncher error. (attached anyway)

Maybe someone had a similar problem on OS X? Couldn't find anything consistant on the forum with "yjpagent"

-nodje



Attachment(s):
#7905_start_error_-agentlib-yjpagent.txt
0
Comment actions Permalink

For me it is the very same and happens after I have update from svn 1.4 to 1.5 via the command line. CPU load on my MacBookPro is ~ 80% while IDEA tries to update its svn status (as indicated by "(updating ...)" in the 'Changes' view). The load is high for about 10 minutes. Additional, if I try to commit via IDEA I get the following error:

Commit failed(...): svn: unkown host svn: OPTIONS request failed on /....

Commiting via command lines works without problem.

0
Comment actions Permalink

BTW, the same problems continue to exist for Selena-7920

0
Comment actions Permalink

Hello Roland,

error like "unknown host" indicates that it is configuration problem..
it is not related to Subversion integration performance at all.

please be sure that your proxy configuration (or default Idea proxy is disabled if should be) is ok.
Here is description about how to disable proxy (as default) using Subversion "servers" file: http://www.jetbrains.net/jira/browse/IDEADEV-28522#action_272671
A button for proxy disabling will be added into next EAP

0
Comment actions Permalink

Hi Irina,

as I stated above, subversion works perfectly from the command line, so I'm pretty sure that my proxy settings in the .subversion/servers config is correct.

In fact, the following observations indicate nevertheless a problem with IDEAs subversion integration:

  • Disabling the proxy completely (both in IDEA as well as in the servers file) doesn't help when accessing an intranet repository.

  • Using the subversion integration for non-converted 1.4 subversion working directories does work without problems in 7905, only converted 1.5 working directories hang

  • Performing an update hangs with a 100%CPU load for 10-15 minutes for an update on 1.5 directories


...roland

0
Comment actions Permalink

Problems persist in #7925.
If for small sized project, the CPU overload tend to dissapear quite quickly (few minutes), for big sized one, it still takes for ages and quite often eventually leads to an IDEA crash...

Unfortunately I'm still unable to produce a CPU Snapshot.
I'm really curious of what could take 80%-120% processor time and that's for the system and not the user process.

-nodje

0
Comment actions Permalink

I remember having had a similar problem a long time ago. Java is bad at handling symbolic links, it (and thus the Java SVN library) uses a very timeconsuming workaround to treat them. I did not have symbolic links within the project itself (deadly, if you are using Java SVN tools), so I just re-created the IDEA project in place without going through the symbolic link to my external disk.

Peter

0
Comment actions Permalink

Hello Peter,

I remember having had a similar problem a long time ago. Java is bad
at handling symbolic links, it (and thus the Java SVN library) uses a
very timeconsuming workaround to treat them. I did not have symbolic
links within the project itself (deadly, if you are using Java SVN
tools), so I just re-created the IDEA project in place without going
through the symbolic link to my external disk.


The situation has actually improved since that time - symbolic links no longer
cause a huge performance hit in SVNKit.

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Thanks for the info, Dmitry!

Peter

0
Comment actions Permalink

Thanks Peter, you saved my day ! ;)

In fact, I used to use symlinks to aggregate my current projects in a single place and worked from within the symlinked directories. When I re-open the project's pom.xml from the physical directory, subversion works fine again (5 seconds for an svn sync instead of 15 minutes).

Could it be, that this symlink issue in SVNKit rearouse for subversion 1.5 ? It worked smoothley in the symlinked dir before svn 1.5. support was added. Maybe it's an OSX specific issue, too, don't know ...

roland

0
Comment actions Permalink

Same for me, thanks!
It seems to be ok so far for me. I was using symlinks pretty heavily under OS X.

-nodje

0

Please sign in to leave a comment.