Choices for integrated code review in IntelliJ

Hey folks,

I'm considering a formal code review tool / process / plugin for our team of 5-6 developers and wondering what options people have chosen that they're happy with?  My strong preference would be to have something built into IntelliJ and not be web-based, but I would consider anything that people might work well.

Our environment in a nutshell:

  • SVN (hosted in European office - we're on the East Coast)
  • Hudson (Also hosted in EU)
  • Maven for dependencies & builds
  • 1-2 million lines of code across 100+ maven projects
  • All devs use IntelliJ Ultimate

Since the changes tab / diff viewer in IntelliJ doesn't cache change sets it's extremely painful to go through incoming changes across a line with latency, so we were thinking of formalizing the process.  We don't have the freedom to change our tools too much, but small adjustments / tool wrapping might work.

In the past we used Eclipse which caches all incoming changes.  This allowed us to easily see all incoming changes, irrespective of changeset and made non-formal review pretty painless even across the pond.  Eclipse isn't without issues however, so we all agreed a couple of years ago that IntelliJ is the better tool for us.  Sadly since then informal code review has completely stopped because of how painful IntelliJ makes this process.

I'd be grateful for any suggestions.




Hi James,

I'm afraid the problem is a bit unclear - as far as I understand you said that would like to be able to check changesets which belong to particular task directly at the ide. But it's already possible to do that (check the screencast):

  1. Go to 'changes | repository';
  2. Navigate to any revision - list of affected files will be shown at right;
  3. Call 'show diff' for every changed file;

I might have not understood the problem though, so, please provide more details if the steps above don't solve it.


Thanks for the response and video.

I'm more referring to tools for formal code reviews, such as Atlassian's crucible.

The changeset viewer is far far too slow for the purpose.  Within a change set, each diff has to be loaded by IntelliJ individually.  The problem we face is that already since this morning (it's not even 11am) we have 26 incoming changesets, each with between 1 and 12 changes files.  The "auto refresh from repo" option and incoming changes views are great, but far too slow to make it usable as a way of reviewing incoming changes from your peers.  If we used it we simply couldn't get any coding done of our own.

You can even see in the video (which presumably has a repo that's more local than mine) when you look at the diff it takes a few second to load - that already is too slow, but add a little latency and more change sets and the problem is exacerbated.

This problem would be somewhat resolved if this feature was implemented: IDEA-106107 - that would mean that I could select all of the 26 incoming changesets (perhaps filtered by the user I've been assigned to review) and browse the diffs without loading each file one by one.

I can see 3 options for our team:
  1. Use a formal tool that allows us to add comments, accept / reject changesets, send feedback etc
  2. Use the repo browser in IntelliJ to informally review changes if all incoming diffs were locally cached so it was fast
  3. Don't peer review code - this is status quo since shifting from eclipse and it sucks.

Ideally my question was posed to dev teams that have a format review process in place that they're appy with.  The simplest solution for my team would be improving the diff viewer, i.e. IDEA-106107

Thanks for taking the time to respond.  I hope I clarified my question a little.



Yes, James, the problem is clear now.

  1. As you already mentioned, being able to improve changset viewing performance would provide good informal review facility. Will ask the responsible developer to comment here about his vision on the problem and possible ETA;
  2. We've recently adopted crucible here as well but we use git, so, the whole repo is already available at local machine, effectively eliminating that diff construction lags. One of our engineers has also implemented a small plugin for that. It's open-sourced and located at github, so, you can try the plugin and post your suggestions/bug reports to the github wiki. It might be possible to provide that caching stuff there;



Hi James,

Regarding the svn integration performance - the discussion will be continued at the ticket (responsible engineer will comment there)



Please sign in to leave a comment.