Introducing Issue Verification and Ship-It! Revocation

We’ve all been there…

It’s a week before the deadline. Your team is working through the night, eager to land their changes as quickly as possible. Your teammate, Jake, was feeling frazzled as he was trying to fix all the issues that had been filed on his review request. He’d just finished the issue you had filed and marked it “fixed.” Shortly after, another teammate files a new review with a “Ship It!” Breathing a sigh of relief, and eager to go home, Jake immediately lands the change.

It wasn’t until after the release of the product that you realized Jake had missed something important in your feedback. While his change had fixed the bug, it had broken another feature. You hadn’t had the chance to look over his change after he’d fixed it, since you were busy and it had fallen off your dashboard once it landed. If only Jake knew you wanted to take a second look, the release would have gone a lot more smoothly.

With Review Board 3.0, you can prevent this from ever happening again. We’ve added a new feature, Issue Verification, which keeps issues open until the reviewer has a chance to verify the fix.

You can activate this feature by checking the “Require Verification” box when opening a new issue.



Once the owner of the change resolves the issue as “Fixed” or “Dropped,” the status will change to “Pending Verification.” At this point, the issue is still considered open. It will be up to the reviewer to look over the fix and click “Verify Fixed” before it can be closed.


Filed a Ship It! prematurely and wish you could take it back?

Now you can with Review Board 3.0’s new Revocable Ship It! feature. The “Ship It!” label on any reviews you file will now have a little “x” button. Just click and confirm that you want to revoke it, and the review’s “Ship It!” tag will be removed, with the “Ship It!” text crossed out in the review.



These new features will help ensure that important reviewer feedback is addressed and that an unintentional or outdated “Ship It!” review no longer lets changes into the codebase prematurely. These features have been requested by many of you, and we would love to hear if they improve the review process for your team!

Read More

Introducing Slack Support in Review Board 3.0

One of the highlights of the recently release Review Board 3.0 is our new integration with Slack. Projects and companies around the world use Slack for communication and collaboration within their teams. It also hooks into third-party products and services to provide live updates in chat. By enabling the Slack integration in Review Board 3.0, you will be able to keep your team informed of discussions and updates on review requests as they happen.



You can create as many Slack configurations as you need for your company. Each configuration can be customized based on your needs. For example, review requests for different groups can go to different channels. Those containing sensitive information such as security fixes can be filtered out entirely.


Getting Started

First, create an incoming Webhook integration on Slack. Once it has been created, Slack will generate a Webhook URL, which you’ll plug into Review Board in your new configuration. To create that configuration, open the Administration UI in Review Board and navigate to Integrations → Slack → Add A New Configuration. Paste your Webhook URL, like so:



Now you’re ready to customize your configuration by adding conditions. By default, a Slack configuration will post all discussions and updates to the channel. If you want to limit what’s posted, you can add one or more conditions to your configuration. These will operate off the data in the review requests being sent to Slack.



You have a lot of options when adding conditions. You can include or exclude messages depending on the review groups, repositories, summary and description content, branch field, and more. Custom extensions can even add new options, giving further control based on data and logic provided by the extension.

We hope this new integration will be a big help for your team members and your company as a whole. This has been a highly anticipated feature for some time now, requested by many of our users. We are excited to finally be able to bring it to you!

Read More

RBTools 0.7.10 is now out

Today’s release of RBTools 0.7.10 some important compatibility fixes for macOS, Git, Subversion, Team Foundation Server, ClearCase.

macOS and Browser Windows

macOS users who have upgraded to recent releases of Sierra lost the ability to run rbt post --open (to open the posted review request in a browser window) due to a Python/AppleScript bug. This is Python bug #30392, for those who are interested.

We’ve worked around this. Your default browser will work once again. Thanks to those who pointed this out!

There’s also a whole new macOS installer coming that should actually work on all setups. We’ll have this on the Downloads page once it gets a little more testing.

Git and Git-SVN

Git-SVN users should no longer encounter crashes when trying to post changes for review. That was pretty disruptive.

Git repositories with submodules containing pending changes no longer cause warnings about dirty repositories when posting changes. They’re not included anyway, and just added to the confusion.

Crazy Subversion Diffs

If you had a line of code being deleted that happened to look like a diff header (say, --- XX (YY)), it could cause some code we have for fixing up diffs to get very confused. That, unfortunately, could lead to lines being excluded from the diff, breaking when you try viewing it in the diff viewer.

We’ve rewritten this code to be very careful about these lines. It won’t get confused again.

Team Foundation Server and Visual Studio 2017

Team Foundation Server users who have upgraded to Visual Studio 2017 can once again post changes. TFS has had a nasty habit of changing their file formats, APIs, and command line options, but after much tearing out of the hair, we’ve restored compatibility.

All versions from Visual Studio 2011 onward should work just fine, so no need to upgrade to 2017 just to use this release.

We’ve also fixed a regression when using the Team Explorer Everywhere adapter.

ClearCase and Cross-Platform VOB Lookups

ClearCase users can now name their repositories in Review Board based on a component of a VOB path, instead of naming it based on the entire VOB path. This helps with the differences in how ClearCase represents VOB paths on different platforms. For instance, a VOB path of /vobs/MyVOB or C:\vobs\MyVOB will now match a repository name of MyVOB.

There are also some performance improvements for looking up VOBs.

And Other Such Things

There are improvements to the Python API, such as not prematurely exiting the process, plus compatibility fixes for Review Board 3.0. We’ve also added a new config option to disable certain warnings in RBTools, which would be especially useful for repository hook scripts.

For the complete list of changes, see the release notes.

To upgrade RBTools, visit the downloads page.

Read More

RBCommons and Cloudflare: Don’t worry, be happy!

There was a major security breach announced this week by Cloudflare, a popular service used by millions of sites. This security breach affected customers around the world, causing passwords, API tokens, private conversations, and more to be leaked into search engines and people’s browser sessions.

You probably have a lot of passwords you’ll need to change this week, but don’t worry, RBCommons does not use Cloudflare, nor do the services RBCommons depends on. Your information is safe!

We recommend that you take the time to ensure you’re using strong, unique passwords (ideally stored in a password manager like 1Password or LastPass), and enable two-factor authentication on RBCommons to make your account even more secure.

To learn more about the Cloudflare security breach, and how it affects you, read their disclosure and see the list of sites using Cloudflare to see if you may be at risk.

Read More

RBTools 0.7.7 is released!

We’ve just put out an all-new release of RBTools. Version 0.7.7 features compatibility fixes for various types of repositories, better support for TFS, and some new features to help with common usage and automation.

You can see the release notes for the full list of changes. We’ll go over the highlights here.

Compatibility/bug fixes

In this release, we’ve aimed to fix a handful of compatibility problems that have been reported to us. Thanks to all the contributors who sent patches!

  • RBTools is once again compatible with Mercurial 2.x. This regressed in 0.7.6.
  • Some error displays are fixed when using the version of Python shipped with macOS 10.11.
  • Perforce gained the ability to post against null client roots, and fixed posting ranges of submitted changelists.
  • Repository lookups utilizing mirror paths or Subversion UUIDs now work once again. These regressed in 0.7.6.
  • rbt post for Git now supports --exclude-patterns when using git-svn or git-p4.
  • rbt land no longer crashes if it can’t determine the approval state on a review request.

Improved Team Foundation Server support

The old TFS support was a bit slow, due to the way we had to interact with the Team Foundation Server command line tools. It also presented compatibility problems, as different versions of Visual Studio shipped different, incompatible versions of these tools.

We’ve now introduced new support that doesn’t depend on their tools and is optimized for our use cases. This means better compatibility everywhere, faster posting, and new features.

To start with, we’re adding the ability to post shelved changesets! You can do this by simply running:

rbt post <shelveset-name>

To begin using RBTools 0.7.7 with TFS, you will need to install our new TFS adapter by typing:

rbt install tfs

New features

We’ve added the ability to specify a destination tracking branch for rbt land. To choose something other than the default (say, origin/master on Git), you can now specify:

rbt land --tracking-branch <branch-name>

If you find yourself needing to pass --svn-prompt-password all the time for your Subversion setup, you can set SVN_PROMPT_PASSWORD in your project’s or user’s .reviewboardrc instead. Just set this and you’ll never have to type it again:


What’s coming next

We’re working toward a RBTools 1.0 release, which will feature enhanced support for Mercurial, new automation commands for use in the upcoming Review Board 3.0, easier setup and installation, and better display of progress when posting changes.

We’re also hard at work on a rewrite of our documentation, with the aim of providing more practical, detailed setup and usage guides for RBTools. These will begin to land over the next month.

If you have any bug reports or feature requests for either RBTools or the documentation, we’d love to hear them! You can file a bug or reach out to us on our reviewboard-dev discussion list.

Read More

The New RBCommons is Live!

We’ve been hard at work these past few months on a major update to RBCommons. This update brings all the many improvements found in the latest version of Review Board.


A more refined look

New RBCommons UI

RBCommons has a new improved look. We’ve modernized the look, polishing things here and there, bringing a much fresher feel to the service. Don’t worry, though, you won’t have to relearn anything. We’ve kept everything familiar.

Along with the new look is support for mobile! You can now use RBCommons from the phone, letting you catch up on reviews and new changes while on the go. Mobile diff review isn’t there yet, but is something we hope to bring down the road.


Archiving/muting review requests

It’s easier now to stay on top of the review requests that really need your attention. By archiving/muting review requests, you can take control over your dashboard and help you get to Inbox Zero (or maybe Dashboard Zero).

Review requests can be archived, hiding them from the dashboard until there’s new activity. They can also be muted, hiding them completely from the dashboard until you opt into seeing them.

Learn more about archiving and muting.


Trivial publishes for review requests and reviews

When you’re making a small change on a review request or clarifying something small on a reply, sometimes you don’t want another e-mail to go out to your team. We’re all busy, and every e-mail we add is one more thing to look at.

RBCommons allows for trivial publishes of review requests and replies. The green draft banner for review requests and replies contains a “Send E-Mail” checkbox, checked by default. To prevent sending an e-mail to your team, just uncheck it before hitting “Publish”.

Learn more about trivial publishing.

Expandable diffs in reviews

Inline Diff Expansion

Ever want to see just a bit more of a diff when reading a review, without having to jump into the diff viewer? Now you can! Just hover over the little snippet of the diff to see the new expansion controls. From there, you can start exploring more of the diff, without ever having to leave the page.


Live HD thumbnails for file attachments

Thumbnails now show more of the content you want to see. They’re no longer just tiny previews of a file. Now they’re big and vibrant, and come to life when you hover the mouse over them, scrolling through the file to show you even more.

Learn more about Live HD thumbnails.


Revisioned file attachments

RBCommons now tracks every revision of a file you upload. Make a change to a graphic, or a PDF document? Simply update the existing file attachment by hovering over the thumbnail and choosing “Update.” Reviewers will be able to go view any revision, and for some files, they can even diff between them!


Diffs for text-based and image-based file attachments

Hey, we were just talking about this!

Image and text file attachments with multiple revisions can now be diffed. You’re seeing one example of this here, with a split diff of two images.

Image diffs make it easy to see how a graphic has changed over the revisions. You can view this in several different modes: Two-Up, Difference, Split, or Onion Skin modes.

Text files can be diffed as well, and this works exactly like the diff viewer.

Working with Markdown? Now only can we diff the source text, but the rendered output as well!

Learn more about diffing file attachments.


New review group setting to auto-add new users

Got a review group or two that you’d like everyone to be a part of, automatically? We’ve got a new option for that! Pull up the settings for a review group and toggle “Add new users by default.” Any new user you invite to your team will be automatically added to the group.


Browsing and posting Bitbucket commits for review on the New Review Request page

New Review Request

Bitbucket users, rejoice! You can now browse for commits in the New Review Request page. If you work in a “post-commit” model, where you push commits and then post for review, you’ll find your workflow’s just gotten a lot easier.


WebHooks for integrating with other services

RBCommons can now talk to third-party services and scripts through WebHooks.

WebHooks are used to notify HTTP services on certain actions (new review requests or updates, new reviews, new replies, etc.). You can use this to interface with in-house tools in response to new diffs or discussions, forwarding them on to other services or automating code reviews.

Learn more about WebHooks.


API Tokens for safer authentication

If you’re working with scripts or services that need to talk to Review Board, you can now create API Tokens and hand those out, instead of handing out a password. These are safer, and have the added benefit of letting you limit what can be done in that API session.

Learn more about API Tokens.


There’s a lot more, but those are the main feature updates. We hope you’ll like the new RBCommons. We know we’ve been looking forward to using it for a long time now.

If you have any questions or hit any problems, you can reach out to us through the “Need help?” button (bottom-right of any page on RBCommons), or e-mail us at

Read More

RBTools 0.7.6 is released!

Today’s all-new release of RBTools 0.7.6 comes with over a dozen improvements, from Mercurial and Perforce fixes to new Team Foundation Server capabilities to automation enhancements.

We’ve fixed some character set compatibility bugs with Team Foundation Server. There’s also new support for posting branched/copied files for review (this requires some changes we’ll be bringing to RBCommons in a big update this quarter), excluding files using --exclude, and specifying a custom path to tf.exe.

Perforce users should see more stability in edge cases, like posting deleted symbolic links for review or when dealing with Unicode mismatches between review requests and changesets.

Mercurial users can now safely use relative, negative, or short revisions when specifying commits to post for review.

We’ve improved RBTools’s behavior when running in a non-interactive console, allowed rbt api-get to be used outside of a source tree, and made it easier to work with paginated responses in the Python API.

Performance has been improved when looking up repositories on ClearCase and Subversion.

These are just some of the improvements made in RBTools 0.7.6. For the complete list, see the release notes.

To upgrade RBTools, visit the downloads page.

Read More

Beanbag’s Best Bad Bugs of February 2016

We’re kicking off a new series here at Beanbag Inc., makers of the popular enterprise collaborative software review tool Review Board.

Beanbag’s Best Bad Bugs highlights the consequences of missing bugs and vulnerabilities before code goes into production.

Before diving into the inaugural list, we want to clarify a few things:

  • Nobody is perfect! We make code review software and even we don’t catch every bug before we go live — it happens! The truth is that with today’s complex deployment models, massive growth in apps and code and ever-growing number of dependencies, it’s nigh impossible to foresee everything prior to shipping. In our view, this makes rigorous, yet efficient, code review more important than ever.
  • The point here is to raise awareness to the need for peer code review by pointing out — with a little levity — where, as an industry, we missed some opportunities.
  • We’ve assigned each Bad Bug a severity rating from 1 (annoying but not damaging) to 5 (very dangerous). This is just our opinion.

Without further ado, let’s get to February’s list!

10. No Visual Studio for YOU!

When you depend on an app and it goes down, life really sucks. That’s what happened to users of Visual Studio Online in February when the site went dark for 5 hours.

The culprit: According to Microsoft:

A SQL stored procedure that was being called was allocating too much memory in one of the critical backend SQL databases. After an extended period of time, this caused the SQL databases to fall into an unresponsive state and resulted in customers being unable to access their VSTS accounts.

Our rating: Bug

Rationale: So, affected teams basically experienced a productivity drain similar to that of every company in a major college basketball town during March Madness. Bummer? Yes. Catastrophe? Not even close. As the article points out, the bigger issue might be how this outage reflects on Microsoft’s overall cloud image.

9. It’s getting hot in here!

A few unlucky customers of the British Gas Hive home automation device and app found it just a tad toasty, to put it with English understatement. Yeah — their thermostat got pegged at 32°C — for us Yanks, that’s just shy of 90°F.

The culprit: According to British Gas:

We are aware of a temporary glitch affecting a very small number of customers, where a certain sequence of commands in the Hive iOS app can cause the thermostat temperature to rise to 32°C.

Weird, but OK.

Our rating: Bug

Rationale: Buyers of Smart Home gizmos right now epitomize early adopters — so they’re likely to be totally cool (ahem) with a bug or two in exchange for the “first on the block” factor. Not to worry British Gas, but don’t make it a habit unless your true aim is to short the entire textile sector.

8. Nest takes home temps to the other extreme.

So many musical references come to mind with these polar opposite smart home foibles — we’ve got Alphabet’s Nest whose battery could lose life, leaving affected customers shivering.

The culprit: The NY Times reports:

“Matt Rogers, the co-founder and vice president for engineering at Nest, blamed a software update from December. “We had a bug that was introduced in the software update that didn’t show up for about two weeks,” Mr. Rogers said apologetically. In January, devices went offline, and “that’s when things started to heat up.”

Our rating: BugBug

Rationale: I know what you’re thinking — whoa — hold on, 1 bug for Hive and 2 for Nest for essentially identical issues? Double standard!

Let me explain.

Alphabet / Nest should be held to a higher standard, in part because they are Google and also because Nest goes beyond temperature to include control of things like smoke alarms and home security, where the stakes are much higher.

To their credit, all reports indicate they busted their tails to make things right for affected customers, but they aren’t likely to achieve their expected share of this growing market if these sorts of mishaps continue.

7. One ringy dingy.

Keeping with our IoT and smart homes theme, Ring (clever name btw) shocked users with a major vulnerability that gave would-be hackers the customers’ Wi-Fi password at the push of a button.

Now, I do think the tech press loves to make hay out of all such stories. In order to actually get the Wi-Fi password, you have to remove the doorbell from the house and press the orange button on the back — not something most hackers would have known to do, even if they could identify a Ring doorbell from the street.

The culprit: Just bad design. The company fixed the issue and all’s right with the world.

Our rating: BugBug

Rationale: Identify theft is really scary and once a hacker has access to your Wi-Fi network, they can potentially access all the info they need to destroy your credit, or worse. So, while the chances are small that a hacker would know that you have a Ring doorbell and that by detaching it they could get your Wi-Fi password, the potential impact is significant.

6. I’m going to need you to go ahead and stay in the office, mmm’k? That would be great.

Commuters tend to not be the happiest of campers to begin with. Daily they face clogged roads, other drivers looking at their phones instead of the light that just turned green, trains that sometimes run on time, but often don’t and countless other indignities.

Enter Bug #6 in our list. According to the English tech site The Inquirer, several travel apps that London commuters use to track the status of Tube lines indicated that every single line was closed at the height of rush hour.

Take a look.


The culprit: All Transport for London had to say was that “a bug” caused the faulty information. The way their system works, all the different tube status apps pull info from a central feed and it was here that the bug manifested itself.

Our rating: BugBug

Rationale: Toyed with giving it a 1 but, just because commuting sucks so much to begin with, felt this particular snafu deserved a 2.

Editor’s Note: This blog was drafted a few weeks ago — our hearts go out to Belgium. Clearly with security on everyone’s minds, one can see how a bug such as this could produce significant unwarranted anxiety.

5. Airlines. ‘Nuf said.

Delta was the latest airline to experience an operations disruption due to software failure. In Delta’s case, a ground operations app that stopped working delayed boarding for about 25 flights.

The culprit: Airlines don’t tell you anything about your flight status or what caused their software to go down. They didn’t comment on the cause of this outage, but assured us they’ve got it under control and it won’t happen again. OK.

Our rating: BugBug

Rationale: Sure, it was only a handful of flights and all this outage did was delay boarding, but airlines have racked up so much ill will with customers that they really have to prove that they care, again IMHO. So that’s why 2 bugs.

4. Creative Cloud Party Crasher.

Let’s shift from IoT to cloud-based productivity apps. As a marketer, this one is near and dear to me. Earlier this month, Adobe faced the wrath of not just marketers, but MacBook-using marketers that use their Creative Cloud, which up and decided to delete the contents of the first folder to show up alphabetically in a user’s root directory.

The mess up hit users of the popular backup tool Backblaze particularly hard. In addition to deleting folders, it also froze users’ back-up capability. Jeesh!

The culprit: A bad update — specifically — contained a “rogue script” that carried out the carnage. Rogue script? One wants more details…

Our rating: BugBugBug

Rationale: Deleting marketers’ folders is going to take a while for Adobe to recover from, IMO. Sure, it’s not as severe as identity theft, but if I lost an entire folder of work, and also the ability to back things up, I’d be really mad. And with software makers pestering customers to upgrade the way they do – and for good reason, since many upgrades are designed to protect customers from new vulnerabilities – it’s really incumbent on vendors to make sure their updates are safe.

3. Would you like privacy with your app? Oh, sorry, looks like we’re all out of privacy.

Here’s a mind-blower — Baidu, the giant Chinese app-maker, has been scarfing up users’ personal information left and right for “commercial” use, saying that they “only provide what data is lawfully requested by duly constituted law enforcement agencies.” Riiiight.

It’s highly doubtful that even a faithfully implemented peer code review process would stop this behavior.

The culprit: According to Reuters:

The researchers at Canada-based Citizen Lab said they found the problems in an Android software development kit developed by Baidu. These affected Baidu’s mobile browser and apps developed by Baidu and other firms using the same kit. Baidu’s Windows browser was also affected, they said.

Our rating: BugBugBugBug

Rationale: Not all countries value customer privacy and freedom the same, but the world’s getting smaller by the day, and these sorts of problems aren’t isolated to just a handful of countries anymore.

2. Wait a sec — I didn’t turn on remote control!

If you were using the NissanConnect EV app with your Leaf, yea, you kinda did. Researchers figured out that they could use the app to hack into a Leaf’s APIs and, with an anonymous GET request, access all kinds of information from the car’s systems, like trips, location and more.

When reading about this app (Nissan has since disabled it) and the nonchalant way it handed over the information about the car to anyone, the details of what the hacker can access fade to the background. Sure, in this case, the hacker can’t access the car’s operational systems. But one certainly hopes this serves as a big old wake up call to all automakers rushing to tap the power of the Internet, software and APIs to deliver cool new features.

The culprit: This one really looks and smells like carelessness. One would think that even the most casual internal peer review on this app and API functionality would have surfaced this issue.

Our rating: BugBugBugBug

Rationale: Nissan is kind of taking one for the automotive team here. The prospect of a hacker accessing automobiles is pretty scary and needs to be prevented by higher coding and review standards.

1. Give me your money, and your identity!

This isn’t a new exploit, but the IRS data breach just keeps getting worse. In February, it was reported that the total number of impacted citizens could be 700,000! Talk about adding insult to injury.

The culprit: As was widely reported in May when the vulnerability and data loss first came to light, the issue was with the Get Transcript feature of the IRS web site, which revealed EVERYTHING to the hackers — income, address, SSN, you name it. Hackers were able to get past the Knowledge-Based Authentication (KBA) — you know those security questions like what street did you grow up on — by using information they stole from other sources. Once in, they literally had access to people’s entire tax returns.

In a sadly ironic new twist, the IRS distributed PINs to all the breach victims, but if you forgot your PIN, the IRS left the same KBA system to fence off your data. At least one victim found that her PIN had been compromised, no doubt by hackers with access to the security question answers that allowed her records to be breached in the first place. Just wow!

Our rating: BugBugBugBugBug

Rationale: If it can get worse than this, I really don’t want to imagine what that looks like — 5 out of 5.

The bottom line…

With all of these bugs, crashes and hacks, implementing the right tools and processes now can save you money and/or your reputation later. You won’t always catch everything, and code review does take additional time up-front, but the savings in the long-run is totally worth it.

We hope you enjoyed this inaugural Beanbag’s Best Bad Bugs. If you’ve got ideas for future lists, send them our way to or drop them in a comment.

Read More

Announcing virtualenv-multiver for Python Development

If you’ve worked with virtualenvs for Python before for development/testing, then you may have hit cases where you really wanted multiple versions of Python installed in your virtualenv. Which, you may actually have working, because virtualenv, in theory, supports this. In fact, you’re supposed to be able to do:

$ virtualenv -p python2.6 my-env
$ virtualenv -p python2.7 my-env

That’d be great, if it always worked. It doesn’t. When your virtualenv gets built, bin/python may end up being a link to bin/python2.7 (or what have you), or it may be the contents instead of a link. Subsequent installs may end up overwriting binaries, producing a python2.6 and python2.7that are both Python 2.7.

Oh and it gets worse. On Mac, with a standard Python install, these binaries actually end up invoking ../.Python, a symlink pointing to the system Python. This link is not versioned. So much for multiple Python versions in one virtualenv on the Mac.

A solution!

We fixed this. Now you can run a single command to get a working environment going, without messing with things or running into problems on the Mac. This is virtualenv-multiver.

Now, setting up an environment is as simple as:

$ pip install virtualenv-multiver
$ virtualenv-multiver my-env 2.6 2.7

Couldn’t be easier. This works both for new environments and existing ones.

This is a beta, so there may be some issues here or there. If this is useful to you, give it a try and let us know!

Read More

RBTools 0.7.5 is here!

RBTools 0.7.5 is now out and ready to install.

This is largely a bug fix release, focusing in part on improved compatibility with Windows, Git, Subversion, Mercurial, Perforce, and Team Foundation Server.

On Windows, RBTools will now first look in %HOME% to find any custom .reviewboardrc files, instead of only looking in the Application Data directory, which will be quite helpful with many system configurations. There are also fixes for using Mercurial on Windows.

Non-Git user? You’ve probably seen that annoying but harmless command not found: git error when posting a change. That’s gone now!

For Perforce users, posting submitted changes or files outside of the client view now work. This had regressed in an earlier release, but you should be in good shape now.

Subversion has seen some more Unicode fixes, plus fixes for rbt post --svn-show-copies-as-adds.

Along with all this, we’ve added a new feature for setting a custom search path for .reviewboardrc. You can set your $RBTOOLS_CONFIG_PATH to a list of paths to search, allowing you to make your version in $HOME take precedence over what’s in your repository, and allowing you to work with centralized collections of aliases in your organization.

See the release notes for the complete list of changes.

One more thing: We’ve simplified installation for those of you using pip to install. Our builds are now directly hosted on PyPI, meaning all you now need to do to upgrade is run pip install -U RBTools.

Read More