RhodeCode 4.6.0 Release: new approach to code-review.

Published on February 17, 2017, by Marcin Kuzminski


The newest release of RhodeCode 4.6 is here, this release includes several new and exciting features including:

  • New versioning of pull requests with updated merge checks.
  • New TODO review notes.
  • Updated comment forms with slash command helpers.
  • Ability to load changelog in chunks.

Take a few minutes to update your RhodeCode instance:
rccontrol self-update && rccontrol upgrade '*'

New to RhodeCode? Download the latest RhodeCode 4.6 Series from our website.
Keep reading for full release details.

We have been working on some exciting new functionality, please read on to learn about what's new in this release of RhodeCode.

Code Review Enhancements

When it comes to Code Review, we did a lot of them here at RhodeCode. Each change introduced by our team goes through a new Pull Request. Because we did so many reviews, we have learned over time what we could improve to make this process much more efficient.

That is why our latest release introduces a new feature, pull requests versioning. This functionality was already partially enabled on the backend, and since release 4.3 Pull requests use internal versioning to pick which comments should be marked as outdated. Now we have refined it, and we rolled out a full versioning support. Since the backend was already tracking the versions, it means your old Pull Requests will have the versioning enhancements if you upgrade to 4.6 release.

Diff the Diffs...

It's not an easy task to do a code review, especially if changes are big. We're a big fan of small changes, but sometimes the big ones are unavoidable. Reading through that 977 lines of changes can be a challenge even for the most experience.
RhodeCode already can automatically pick people for a review, based on whose code you are trying to change. This might help to pick the right people to do the review, however, someone still needs to look at those changes, and maybe send the author his feedback.

For large changes, often problem arise when someone reacts to reviewer feedback and sends an update. Before you had to either ask the author what has changed or re-check the whole code for changes. It's hard in such cases to catch accidental changes that weren't in the scope of feedback. The ideal situation would be to allow users to simply view changes since the last update, or better since last review.
Well, now it's possible. Starting from version 4.6, RhodeCode will show to users each individual update as a new version, reviewing that 1000 lines of code again is no longer required, since reviewer can simply diff changes between updates, together with commit changes so tracking commit rebase or squashing is also possible.

RhodeCode will also track the last version in which a reviewer approved the code, so it's easy for them to look at the changes that were made from the last check. The versioning UI allows you to browse each individual version and see how the Pull Request looked when it initially was submitted and how it changed over each update. I think Gerrit users will like this as it introduces the auditibility of how each pull request was evolving.

versioning of pull requests

In addition we're using the versiong to link inline or general comments to a version. It means you can see in what version of pull
request a comment was made. This is much different approach than other tools out there. We believe the important context for
outdated comments is whole change, and not just few lines above the comment. Now you can simply show outdated comment and click it's version to show exactly the state of pull requests when the comment was made.

show comment at version

In our view, this functionality together with some previously related enhancements such as the smart reviewers, live review chat makes
our system one of the better in the market, and we're not done yet. There're several new features we're planning so stay tunned !

When we worked on the versioning our comment form got a UI overhaul.

show comment at version

In addition to UI changes, we replaced the ctrl+space action helpers to slash commands. This is somehow becomming standard in
many other systems, so we thought we're replace the current action shortcut to be now triggering by a '/'.
For now there are just 4 actions, setting comment type, note or TODO, and setting review status to approved or rejected on main comment form.
If you look closesly you might also notice we introduce comment types. This is another feature we added in code review area.
TODO note main role is to leave a very important comment that needs to be addressed before an approval. TODO notes will show up in merge checks screen, and will block merge of pull request until they are resolved. This gives a nice clear disctinction between a recommendation and a must-have type of feedback.

new merge checks

Changelog

We write our changelogs based on commits made in a linear history. We thought it would be a nice addition to be able to show in efficient way a long list of commits in one view. Now it's possible to load next or previous set of commits from each page.
The DAG graphs also get's re-loaded when doing so you merges or new heads are nicelly shown.

changelog loading

User sessions

We managed to fix a important bug that caused excesive user sessions creation. RhodeCode will now reduce the number of session
objects created significantly. We also added a new interface to manage sessions inside admin panel. We recommend looking at it
once you upgraded to see if there aren't a lot of outdated sessions. It's possible to clean old sessions via the web interface or
API call. We added a cleanup of all sessions option to completely log-out all users from the system if required.

Performance

As usual we added few performance improvements. When using Markdown we now re-use the parser object which allows a nice
boost of performance when rendering previews of Markdown formated texts. We also optimized how diffs will detect language to use syntax highliting, this results in over 30% speed improvement on very large diffs.

Other highlights of this release:

Features

  • Integrations: webhook integration have now additional setting to choose if the call should be made with POST or GET, it's now easier to configure it for Jenkins and use a GET call for example.
  • API: get_repos call now allows to filter returned data by specifying a start root location. Additionally, a traverse flag was added to define if returned data should be only from top-level or recursive.

Security

  • Login: Don't display partial password helper hash inside the logs. The information is not-required and will prevent people worrying about this shown in logs.
  • Auth: use pyramid HTTP exception when detecting CSRF errors. It helps catching this error by our error handler and displaying it nicely to users.
  • SVN: hide password entries in Apache logs using specially generated configuration for Apache Mod-Dav.
  • Permissions: fixed call to correctly check permissions for admin, before admin users were forbidden to delete a pull request in certain conditions.

See the full list of changes in the release notes.

As usual, the update process is a simple one-liner: type
rccontrol self-update && rccontrol upgrade '*' in the command line interface. Done!

Performantly yours,
The RhodeCode team.