Last week we upgraded our servers from Subversion 1.6 to 1.7. This is a major release filled with many performance improvements and we’re excited to get it out there. While it was released last October, we tend to take our time with upgrades until any bugs or issues have been ironed out.
What’s new
The improvements and “features” in Subversion 1.7 will be mostly invisible to you in terms of how you use Subversion. However, the performance improvements are drastic. The full release notes are on the Subversion site, which I highly recommend you read. Here is the quick list.
WC-NG: A faster and completely revamped working copy structure. Instead of having .svn directories spread out, they are all in one place in the root of the working copy.
HTTPv2: A highly improved method of accessing SVN over http. You must have both a 1.7 server and client for this to work.
svnrdump: It is now possible to perform an svndump directly from the Subversion client. You can read more in the documentation.
On the server side there are also a bunch of improvements to help performance:
Caching: While svn has supported caching like memcached, it now has its own caching methods that can be tuned. We plan to start small and get more agressive as we go.
Compression: To reduce network latency and bandwidth SVN 1.7 supports network compression.
There are many more CHANGES which you can view on the Subversion site. These are the ones with the most impact.
How much better is it?
All of this sounds great, but how fast is it? We decided to run some benchmarks to see for ourselves. For this benchmark we ran SVN checkouts in 1.6 and 1.7 against a test repository on our servers from a machine inside of our internal network. We wanted to test across a network over HTTPS since that is how you access your repositories. The repository was about 20mb with around 1300 revisions.
Here is what we found:
1.6 client / 1.6 server: 16 seconds average
1.7 client / 1.6 server: 16 seconds average
1.6 client / 1.7 server: 8 seconds average
1.7 client / 1.7 server: 7 seconds average
If you look closely, it’s twice as fast just by upgrading the server to 1.7! The interesting part about this result is that having a 1.7 client and server was only a second faster. And having a 1.6 client still made the checkout faster with a 1.7 server. We plan to test on larger repositories since HTTPv2 should have drastic performance improvements on the number of calls.
Another bonus is that deployments are faster as well (due to SVN updates and checkouts). Based on our internal benchmarks the average release time for Subversion repositories improved by 45%!
I plan to do a follow up post once we upgrade showing the results of caching and compression.
Enough, upgrade!
Make sure to read the release notes along with the compatibility chart. You may have upgraded your local working copies already, since 1.7 working copies work just fine with 1.6 servers. If not, all you have to do is download the latest version of the command line client or upgrade your favorite app.
Some things to note:
Once you install the new version you must run “svn upgrade” on all working copies that were 1.6.
If you need to run “svn cleanup” on a corrupted 1.6 repo, you must do so before the upgrade.
While we don’t expect any issues, we want to know if any problems arise. Please contact us right away if you notice any problems.
We’re also preparing to launch support for Subversion 1.7 next weekend which is going to bring a lot of great performance boosts. We’ve outlined some of the benefits and planning below.
Hello, Mercurial
We launched Mercurial (a.k.a. Hg) support in a closed Beta on Feb 16th. Since then we’ve learned quite a bit and feel it’s ready for you.
We built Beanstalk to make your development process more effective, and part of that is making sure we give you options to best fit your team and your projects. There are different types of version control systems, each with different strengths and weaknesses. We want to give you all of the best options so you can pick what works best for you.
We really like Mercurial and are thrilled to now offer it as a choice when creating a new repository in Beanstalk. It’s a great distributed version control system that has many similar features as git, but may be better suited for your team and your workflow.
We encourage you to use the version control system that works best for your team, and works well for a particular project. It’s not uncommon for us to see Git and SVN repos within the same account, and we expect the same to be true for Mercurial. Only you know what option is best, and now we’ve given you more to choose from.
Coming soon: Deployments for Mercurial
At the moment, Deployments are disabled for Mercurial repositories. We’re working to get these going but are anxiously awaiting feedback to make sure they work well with the nuances of Hg. Otherwise, all Beanstalk features are available immediately. For the curious, we’re currently running Mercurial 2.1.2.
We’re looking forward to improving how we support Mercurial integration as we get more feedback. Please let us know if you have ideas on how we can make the workflow work better for you.
Upgrading to SVN 1.7
For those of you who use Subversion, you may know that a new version was released in October. As with most releases, we usually wait until issues and major bugs are fixed. Next weekend we will be upgrading our servers to 1.7. We’ve been testing internally and it promises tremendous performance boosts, more than doubling checkout speeds!
The upgrade will have no effect on your repository unless you choose to upgrade your local machine to 1.7. You can keep using a 1.6 client or a 1.6 working copy. If you decide to install 1.7 locally, you can upgrade your working copies by running svn upgrade. Please read the release notes for more details. To install 1.7 for Mac OS X, follow our help article. For Windows, download the installer from Collabnet. You may also upgrade your favorite client such as Cornerstone or TortoiseSVN.
We always love it when a Beanstalk customer finds a way to improve their daily Beanstalk workflow and decides to share it back to the community. Today I’m happy to share Erik Kettenburg’s DeployBean, an open source Windows system tray tool for managing Beanstalk deployments.
Erik has gone ahead and recorded a quick screencast covering the features and workflow of DeployBean, which will allow you to easily get your environments and servers up to date from your system tray or a hotkey invocation.
Erik admits that DeployBean could use some polish and has some bugs, but he’s using it every day and is fixing bugs regularly. He’s also accepting pull requests on GitHub if you’d like to make contributions to improve DeployBean.
Thanks for this open source contribution, Erik! What tools have you built to make your Beanstalk workflow better, and can we help share them with the world? Email me!
Some of our customers wrote us with quesitons about some of the design decisions we made and explained that while they liked some of our improvements, we’d removed valuable information from the screens that they’d come to depend on.
Chris, Eugene, and the whole team sat down and looked at the design decisions we’d made, and as of this week, have released a set of improvements to the UI for Beanstalk Deployments.
Who, What, When
One of the biggest complaints we got about the redesign was that we’d taken away the “All Deployments Activity” and made it hard to see where all of your environments were at a glance. That was the opposite of our intent, but we saw what we did wrong: we’d omitted some of the most valuable information about the state of your environments: who deployed most recently, what they deployed, and when it was deployed.
Previously, the date on the overview page was confusing because it was the date of the commit deployed which was different from the date the deployment was inititated. Now, everything is clear and we provide either the commit message of the most recent commit deployed or, for manual deployments, the “comment” that the person generating the manual deployment leaves.
That “deployment comment” is an important feature that many people have overlooked because it provides you with an opportunity to leave yourself and your teammates a note about the reason for the deployment - much like a good commit message, it shouldn’t just explain what you did, but if appropriate, why you did it. We want to encourage our customers and their teams to communicate better, and more effective use of this deployment comment will improve your experience deploying with Beanstalk.
Finally, we pulled the “servers” portion of the enviornment off to the side, closer to environment settings. It was taking up a lot of screen real estate for something that isn’t used every day.
Better Activity
We also took a look at the environment activity and revised it. The focus of our revisions was to put more emphasis on your team and their actions deploying files rather than on the magical robots that work Beanstalk deployments. This means more human-readable messages and information.
Each deployment in the activity stream now includes a count of the commits, files, and even tickets (if a ticketing integration is configured) were contained in that deployment. You can see this quickly and easily, without having to dive into the deployment release notes.
One of the most important things to easily know is who created the deployment, so we’ve increased the size of the user avatars in the activity feed so you can identify a person at a glance. Automatic deployments show the avatar with a special visual indicator that the deployment was automatic, too.
We also include the time of the deployment. Again, we previously had made it confusing by showing the date range of the commits included. No more - what you really need to care about is when the deployment was fired. We’ve also made it really easy to notice at a glance if a deployment was automatic or manual by creating a special avatar style for automatic deployments.
Major Speed Improvements
In addition to the redesign, every page in the Deployments section of Beanstalk has been sped up dramatically thanks to a new caching strategy implemented by Dima. Pages that used to take a long time to load are now nearly instant.
More to Come
A big thank you to the customers who provided useful feedback earlier this year. We have many more improvements that we’re working on to make Beanstalk Deployments even more valuable for you and your team.
Blame is an awesome version control feature that allows you to see who changed every line of your code and when exactly it happened. You can also see a commit message, so if your team is following best practices and always create meaningful messages, you can find out why a change was introduced. Our team uses Blame every day to find answers about our code.
The Initial Design
We first introduced Blame in Beanstalk in January, 2011. We didn’t plan to work on it, but I wanted it so badly that one evening I just sat down and wrote a quick and dirty implementation that worked. It was literally a few days of coding.
Then we added design, polished edge cases, fixed bugs, tested and delivered it. And it was working perfectly since then…except that sometimes it was horribly slow. So slow that it would sometimes timeout on users.
We knew that it was only the first iteration and that one day we will go back and improve performance. We guessed it was slow because every blame required a live disk intensive operation to fetch a data from a repository. And, as usual with performance issues assumptions, we were completely wrong.
Last week I found a small time slot between my iterations so I started looking for a fairly compact task that I can accomplish right away without too much back and forth. So I looked into Blame. I did some profiling to see if I can make it any faster without scheduling a lot of developer time for it.
And boy was I surprised to find out that the main reason why it was so slow is because of syntax highlighting! In my tests, when I removed syntax highlighting completely, Blame rendered almost instantly compared to the highlighted version. And here’s why.
Investigating Slowness
We use the Pygments library for code highlighting. It supports dozens of languages and is extremely fast, so we love it. But since we interact with Pygments through command line, every call is expensive. If you want to highlight one huge file, Pygments will process it in no time. However if you want to highlight 130 small files, it will take quite some time just to spawn all those Pygments processes.
This is an excerpt from one of our Blame pages:
You can see here chunks of code highlighted with a red color. These represent pieces of code that we used to send to Pygments one by one for processing. And since there’s a whole lot of them, creating a separate process for each one was overkill. Not only was it slow, but it was also tough on our servers because it required Beanstalk to spawn hundreds of small highlighting processes. Yikes!
The Resolution
I realized that there was no reason to ask Pygments to highlight something 100 times when I could just ask one time.
Now only one Pygments process is created to highlight a blame as a whole. According to my before/after benchmark on some files this method was up to 22x faster. Quite an improvement simply for replacing a highlighting logic, eh?
One of the reasons why we used to highlight chunks independently is because of the way VCS libraries usually provide Blame data. SVN Ruby bindings, grit and mercurial-ruby all serve Blames as an array of line objects. Every line is a mix of metadata and code. There was no easy way to pass code to Pygments for highlighting, because it wouldn’t separate it from it’s metadata and we would end up with a mix of highlighted giberrish.
So I rewrote the Blame parsing logic in all three libraries to return code separately from metadata. This way we could highlight all code at once, then iterate it together with the metadata and build a fancy HTML. You can see how I implemented it in mercurial-ruby in case you’d like to implement a similar fix for your own code:
So this is it! One crazy night of code and Blames are now up to 22x faster. I regret that I didn’t look into this performance bottleneck earlier. If I knew it was so simple to fix, I’d have done this long time ago. Oh well.
We will continue improving performance of various parts of Beanstalk step by step. Even though Blames are much faster now, we still think they are pretty slow (some requests can take several seconds to complete). I will let you know what a next round of performance optimization will bring ;)
Hot on the heels of a visual improvements release from a couple of weeks ago is a release containing two major performance improvements.
Blame Faster & Browse Faster
Blame is an awesome feature in version control that allows you to browse a file’s history in a special way to see the latest revision of each line in the file. If you’ve ever looked at a line of code and wondered, “Who wrote that?” or “Hm, I wonder why that’s there?”, the Blame tool is right there for you.
Beanstalk has a visual way of working with Blame, and as of today’s release the blame tool is working as much as 22x faster! You can find the Blame button on the top of every file detail page in your repo and try it out for yourself.
Repository browsing has also benefited from a significant performance improvement in this latest release, meaning you can get to the file you’re looking for quicker than ever before.
Increased Security for S3 Backup Buckets
One of our Business Account features includes automated repo backups to your own Amazon S3 account. Now, to keep your Amazon account more secure, we allow you to specify a custom bucket name and its credentials for backups.
If you’d like S3 backups of your Beanstalk repos, consider upgrading to a business account today. You also get more robust deployment tools, additional security features for your team like IP restrictions & logging, and of course more users and repos.
And as always, you can review this week’s full changelog.
The crew at One Mighty Roar have released their latest update to their Beanstalk client for Android dubbed Beansprout, and it’s a pretty mighty update.
One of my favorite updates included is a beautiful new diff screen and mobile comments for mobile code review.
There’s lots feature enhancements, major design overhauls, and of course requisite bug fixes. Here’s a summary:
Redesigned UI.
Added a user management tab to the home screen which allows you to set user permissions on the go.
Added support for comments.
Added the ability to view highlighted file differences for a commit.
Commit summary page layout modified for easy swapping between changed files, file differences, and comments.
Added pull-to-refresh to many screens.
Improved stability with background updater and notification system.
Switched to ICS-style menubar and removed the old-style menu options.
Fixed a bug where the app was crashing on load for ICS users.
