What is Early Access Program

We at JetBrains believe that making tools for developers should greatly involve listening to developers. Our Early Access Program lets development community closely participate in discussions devoted to IntelliJ IDEA and influence development planning, from early stages onwards.
Early Access Program allows you to try pre-release versions of our software to evaluate features that will be added to the next release.

Be Careful

Icon

It is important to distinguish EAP from traditional pre-release software. Please note that the quality of EAP versions may at times be way below even usual beta standards.

What is IntelliJ IDEA 11.1?

IntelliJ IDEA 11.1 is a minor feature update for IntelliJ IDEA 11, released on March 28, 2012. IntelliJ IDEA 11.1 is a free upgrade for users of IntelliJ IDEA 11.
IntelliJ IDEA 11.1.5 has been released on December 18th, 2012. You can download it from http://www.jetbrains.com/idea/download/

I had previously chosen the option not to prompt me about which window to open a second project, but open in a new window. After moving to EAP version, it remembered not to prompt me when opening a second project, but it chose to open it in the same window. This was easy to fix by re-enabling "Confirm window to open project under General IDE Settings. I just opened http://youtrack.jetbrains.net/issue/IDEA-81150.

Unfortunately this is a side effect of some another problem. If you please could find the very first stack trace and post it here. For this you can either dig your log or launch idea.bar or idea.sh in a console and it'll be the very first thing to be printed out.

java.lang.NoClassDefFoundError: com/intellij/util/ui/UIUtil
at com.intellij.idea.Main.main(Main.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.exe4j.runtime.LauncherEngine.launch(Unknown Source)
at com.exe4j.runtime.WinLauncher.main(Unknown Source)
Caused by: java.lang.ClassNotFoundException: com.intellij.util.ui.UIUtil
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
... 7 more

RC3 (117.46) still contains a rather old svnkit pre-release build of 1.7 (SVN/1.7.2 SVNKit/1.7.0-SNAPSHOT (http://svnkit.com/) r8919_v20120229_2018). Please consider upgrading it to the latest svnkit release (currently 1.7.4-rc1) before final release.

Apart from that, the newer svnkit version probably incorporates most improvements that were made to svn between 1.7.2 and 1.7.4, some of which were errors and assertions that happen with certain edge cases in the working copy (some happen during upgrade from 1.6 to 1.7). I think these fixes are important for the final IDEA 11.1 release, because it will impact how users perceive the svn 1.7 support (right after release, a lot of users will start upgrading their working copies, ...).

It seems the EAP doesn't include jna.jar with svnkit (in the svn4idea plugin). Normally svnkit ships with jna.jar, and it's important for improving performance and making certain native calls. It was included in 11.0 (and older releases), but seems to be missing form the EAP's of 11.1. Is this intentional?

Rodney,
As far as we know, deadlocks on Mac OS X when it's impossible to get the thread dump with jstack are caused by a bug in the Apple JDK, which is fixed in the latest Developer Preview of Java for Mac OS X. Unfortunately there is nothing that can be done to fix this problem on our side; please wait until the Developer Preview becomes a public release.

Hi - when will 112.666 or greater be available for EAP? http://youtrack.jetbrains.com/issue/IDEA-80387 is absolutely killing me. I am on 11.1 (117.105 and it is killing me having to restart EVERY TEN MINUTES to keep my debugger and run-dialog working. Urgently want any version that doesn't do this. Very frustrated,

Is anyone else seeing SVN 1.7 corruption issues using recent IDEA versions? I installed 117.216 and had to roll back because I was spending more time dealing with SVN corruption issues. I just switched to 117.359 at the end of last week and am starting to experience SVN corruption again. This manifests as IntelliJ reporting that there are (partial) incoming changes, but update doesn't get them. Using TortoiseSVN on the directory reports there is nothing to update yet the files/changes are missing. The only way I've found to fix this is to rebuild the SVN database for the affected directories (using update --set-depth empty and update --set-depth infinity), but that is cumbersome. After a few days the corruption gets so bad that even that doesn't work anymore.

Obviously this would be a SVNKit bug and not an IDEA bug, but I'm writing about it here to see if other people are experiencing it and perhaps JetBrains can track down which versions of SVNkit have it and which don't. I did not see this with 11.1.1 GA.

Partial incoming changes do not indicate a corrupted SVN working copy or a bug in SVNKit; it's simply a problem of IntelliJ IDEA not detecting correctly which changes are applied to your working copy and which are not. All changes are in fact there in your working copy.

I know that Partial doesn't mean there is a problem. The issue is that after performing an update with IDEA the changes are missing. Sometimes that means new files are missing, sometimes file changes are missing. The Incoming changes panel reports that they are missing, but performing an update doesn't do anything. Similarly, doing an update from CLI or TortoiseSVN reports that the directory is up-to-date. It has to be a SVN database issue, otherwise the issue wouldn't span multiple tools, but it always starts after an IDEA update (alas, I think it's a SVNkit bug).

As a side note, I work against an extremely active SVN repository, we often have over 100 check-ins per day. This results in lots of updates and lots of change sets per update.

Maybe you've seen the "Checksum mismatch" error, which was reported in issue IDEA-83673? After hitting this, your working copy gets corrupt, because the affected node thinks it's up to date, but it's not ('svn info' says there is a gap between 'Last Changed Rev' and 'Revision', but the history of the file shows that changes were made after 'Last Changed Rev' and 'Revision' – see the issue comments for some more explanation). After that, this node will not be updated anymore.

I've had this problem with 11.1, and thought it would be fixed in the newer IDEA versions (maybe because they carry a newer SVNkit), but it seems that the issue is still present. I hope people from JetBrains and/or SVNKit are actively working on this problem, because it makes the svn support in IDEA very unstable (4 out of 5 colleagues of mine have run into this).

It's silent corruption. I had a lot of the checksum errors with 117.216, but haven't seen any using 117.359. It just reports the update as completed successfully. I usually don't notice there is an issue until I rebuild my code and find out I can't build due to missing updates. At that point I'm dead in the water... IDEA shows there are missing files but nothing will retrieve them. The only workaround (short from doing a brand new checkout) is forcing SVN to rebuild its database for the affected directories. This is easy when the directory doesn't contain any changed files, but a pain when it does (copy them out, rebuild the directory, copy them back in).

Also note that with SVN 1.6 you could just delete a directory and "svn update" would fix it. Using svn 1.7 this doesn't work as deleting the directory doesn't wipe the database records for it. The answer is using "svn update --set-depth empty", which will empty out the directory and purge the SVN database records for it (local DB, not repository), followed by "svn update --set-depth infinity", which will retrieve the files and rebuild the DB for it.

Yes, I've seen checksum mismatches, etc, though note that I'm using svn 1.6 working format. There is an 11.1 option to use an external svn exe (supposedly to speed svn ops) but perhaps that would address the corruption issues you've experienced.

Looking at the svn4idea plugin in the 117.359 release candidate I see that the version of svnkit used is 1.7.5-SNAPSHOT. This either means they intend to ship with a non-released version of svnkit or that the release candidate is invalid (since it wouldn't represent the actual release if they change the dependency). Is there a specific bug in the released svnkit they're avoiding with the snapshot or is this just a release candidate packaging mistake?

The stability of the VCS component is important - a defect there can derail a developer for a while with the potential to lose uncommitted changes. If a bug exists in the commit chain it could, depending upon the team branching policies, derail the whole team until the problem is identified and rolled-back.

We've been hit by VCS integration bugs in older IDE releases (IDEA and in eclipse, this isn't a finger pointing exercise), we'd very much like to minimise the chance of seeing history repeat itself...

We have a lot of developers using 11.1.1 with SVN 1.7 and have seen little to no problems with it. I've started testing the 11.1.2 versions and have had a ton of issues with them. I've never lost uncommitted changes though. Worst case has been creating a patch file, wiping the project, doing a clean checkout, re-applying patch. Nothing lost other than a few hours of my time ;-) I will also add that this is the price one pays for running EAP versions... the initial EAP versions of 11.1 completely hosed up our Flex modules. The 11.1 release version had no problems with them.

Having had IDE/VCS integration issues in the past, the fact that Jetbrains is packaging a non-release version of their integration dependency was enough to block our upgrade from 10.5 to 11.

That this still hasn't been resolved or explained, since my previous comment on the 117.359 build, has driven most of our IDEA users off the product (they are now using Eclipse) and I am now under pressure to transition as well.

It's a shame that something so simple as fixing or explaining a dependency decision could have this effect but this has effectively ended our project team relationship with IDEA (sadly for me as I prefer it to Eclipse).

Sorry, but I'm pretty disappointed lately with the poor SVN support of IntelliJ IDEA, continuing stability problems, corrupted working copies, ... this causes a lot of wasted effort and loss of time.

If Jetbrains currently already works together with the SVNKit team, you should work even more closely together I think (or look towards other solutions if necessary). The current situation is simply unacceptable. I cannot trust my IDE to integrate well with my version control system, one of the most fundamental pieces of infrastructure in a professional development environment. This is now going on already since the first 11.1 release. I have yet to see a release with solid SVN (1.7) integration that I can depend on.