One of the things that I've been arguing is a key advantage of Mercurial, and distributed version control systems in general, is that they let you iterate much more quickly than traditional systems.  This stems from many areas—Mercurial's operations are generally faster, its superior branching ability means we can easily keep developing new features even while we’re in the release candidate phase, and its vastly better code auditing makes it a lot easier for us to find problems when they arise—but that’s all for naught if you don’t have anything to show for that faster cycle.

Code reviews got a heck of a lot better

We know that one of the major features a lot of you love about Kiln is its code review UI.  While we generally really like the review system, we felt that there were a few key weaknesses we wanted to address:

1. Having a review with multiple users is hard.  Kiln 2.3 and earlier suggested you create separate reviews for each person you wanted to involve.  This made having a single coherent conversation with multiple developers unintuitive.  While multideveloper reviews are rare at Fog Creek, we’ve found that they’re extremely common for a lot of our customers.
2. Users who had a lot of code reviews frequently could get lost in what was going—especially if they had multiple code reviews on the same changeset.  Unless users thought to give the reviews unique titles at creation time, they’d end up with a pile of reviews with nearly identical titles.
3. Frequently, a review would spark a need for making a case in FogBugz.  For example, a given line of code might not be wrong, but might make a developer realize that syadmin action was required.  To make a case, you’d have to leave Kiln, go to FogBugz, make a case, tie it to the review, and then go back to Kiln.  This was annoying.
4. Customers had trouble figuring out how to use the UI.  Buttons that controlled the review were at the top, but the controls for adding comments were all at the bottom.  This split made it easy for new users to get confused by the system.

 

We tried to address all these issues with a brand-new UI:

First, all of the actions you can use to modify a review are all located right at the bottom.  We’ve tried to make it clear how to resolve and comment on a review, and made it clearer that you can resolve a review with a message.

Second, we’ve made it easy to make a case right from any comment in a review.  If you see something that doesn’t really need to get fixed as part of a review, but that you realized was a bug that needed to get addressed elsewhere, or inspired a great feature idea, just click the “Make Case” button on the relevant comment.  We’ll make a case in FogBugz and immediately tie it to the review, making it easy for you to keep everything tightly linked together.

Third, we made it easy to retitle a review at any point: just click the title.  If you have a pile of nearly identical reviews, just give them better names to help disambiguate them.

Finally, we’ve made it much easier to have lots of developers contribute to a review by making it clearer that a review can be assigned to anyone, and by autosubscribing anyone who has seen a review.  We’ve found this system makes it feasible for lots of developers to actually stay on-top of a review, while leaving the old one-on-one style in tact for those who like the current way things work, and making sure that some developer ultimately has responsibility for resolving the code review.

While we’ve been enjoying this new behavior internally, it’s brand-new, and a change from how Kiln’s traditionally worked, so we’d love your feedback.  If you hate it, we’ll kill it.  If you have great suggestions, we’ll add them.  Just let us know.

 

Diffs are way more powerful

At the center of every source control system are diffs.  They’re the be-all end-all at the end of the day: if the system can’t tell you what’s changed, then it’s not really doing you any good.

For Kiln 2.4, we dramatically increased the power of our diff system.  You can now change tab size, toggle whether to show whitespace, ignore whitespace changes completely, and finally, in answer to one of our most-requested features, display diffs side-by-side.

You can learn all about Kiln’s amazing diff controls on our StackExchange.

File histories now show a DAG

Everyone knows that their repository is a DAG, but what’s not always well exposed is that your file history is a DAG, too.
Beginning in Kiln 2.4, we expose that DAG in the file history view, making it much clearer what the actual history of your file was.

 

And a lot more

Those are five of the things we're most proud of, but check out our full release notes if you're curious to take a look at everything we just shipped. Some of the things I didn't get a chance to talk about are: 

• You can tell Kiln to ignore files
• Kiln now supports Mercurial bookmarks
• Massive bfiles improvements
• Search improvements

Plus, in case you missed it, we’ve added these features to Kiln since the new year:

• Changesets related to a case are shown inline in FogBugz
• Kiln allows jumping to the electric DAG directly from a given changeset
• Reviews are now repository-independent
• Reviews can be assigned to virtual users
• Review comments can be threaded
• And more!

Final Thoughts

We’re very excited about where Kiln is going to go this year.  We really believe that having such a rapid release cycle will make us much better able to respond to your bugs and feature requests, and ensure that you get a steady stream of improvements throughout the year.

If you have any questions or concerns about any of this, don’t hesitate to contact us.  We’re always listening.

A lot of Kiln features come about because we have an itch to scratch. In fact, the very idea of Kiln arose because I wanted to be able to stop asking sysadmins to make new repositories for us and Tyler wanted a code review tool that didn’t stink. Then, our JSON API came about because customers wanted to be able to build on top of the great foundation that Kiln provided. Then, code search happened because it had become so easy to put everything into source control that we were having trouble finding anything.  Finally, our increasing movement to allow code reviews to float among related repositories has been driven by a mix of internal and external desire to make them ever more flexible.

But there’s one feature that few customers have asked for, but that we feel is really important: making it very easy to share your source code with others. Open-source projects are extremely common these days.  Many companies, including Fog Creek, share a lot of code with the broader community. While Kiln provides a whole host of tools that would make doing open-source development a lot easier, most projects didn’t want to use Kiln for one key reason: you needed to log in to Kiln to view source code. While that’s what you want 99.9% of the time, it can be a real bear when you’re just trying to share open-source code with your customers or the community at large.

We were initially nervous about how to implement this feature. We wanted to make it easy to share code with others, but we also wanted it to be impossible to accidentally make private code public. After playing with a few different designs, we settled on one that we believe makes a lot of sense, keeping your private code fully secure while making it really easy to share what you want to be public.

So we’re thrilled to announce a brand-new feature in Kiln 2.2: Public Projects. All repositories located in a public project can be accessed by anyone with a web browser; no log-in required. Visitors to your site can see a customized version of Kiln’s activity feed that lists only activity that’s been going on in public projects.  They can subscribe to the RSS feed to stay abreast of updates, browse through your code, use Kiln’s phenomenal repository search, and clone the code to their local machines. Public projects are prominently labeled, making them hard to miss.  And because you can only make things public at a project level, you never have to worry about accidentally exposing your work to the world as you reorganize a project or work in the permissions pane. We really believe it’s the best of both worlds.

There’s no better way to explain this feature than to show it off.  So, as of today, we’d also like to announce the Kiln Mirrors Project, located at http://mirrors.kilnhg.com. The Mirrors Project hosts mirrors of a variety of open-source projects, such as the Python programming language and Mercurial itself. It’s not only a convenient place to grab copies of your favorite open-source software; it’s also a really easy way to see what Kiln offers without even signing up for a trial. If you like what you see, and you’re an open-source project, don’t forget that Kiln has a free edition for up to two users, and we’re generally happy to expand that for genuine all-volunteer open-source projects. It’s very easy to get started.

Happy coding!

Django is an increasingly popular Python web framework, being used by such companies as Google and the Washington Post. Django has a concept of “middleware,” which allows you to stash extra processors between your application and the low-level framework. Today, I took some time to write FogBugzMiddleware, a piece of Django middleware that allows you to automatically report 500 and internal 404 errors to your FogBugz install. Installing it takes just a few seconds, and will immediately allow you to start using FogBugz to manage your website’s crash reports.

You can download the software at http://bitbucket.org/bpollack/fogbugz-middleware/. The software is free for use and redistribution under a BSD license.