The JIRA DVCS Connector combines all the features of the JIRA Bitbucket Connector and JIRA GitHub connector — and a couple more that are brand new. If you’re using a previous version of either plugin, you’ll want to install the new plugin and check out the new features (and some bugfixes).

From JIRA you can:

• Track commits, monitor source code edits, and drill through to source files
• Push commits to JIRA simply by referencing issue keys in commit messages
• Map unlimited public and private Bitbucket and GitHub repositories to JIRA projects

What’s New

Redesigned Commits Tab

We’ve completely redesigned the JIRA ‘Commits’ tab with a new interface. For every repo commit that references a JIRA issue key, you’ll be able to:

• review total number of lines added and removed from a file
• view the commit message and owner
• branches used
• link to the entire changeset and individual source files
• updates appear in your JIRA Activity Stream

Easy Admin

The look and feel for the administration screens have been updated; you’ll notice that it’s easier to review and manage multiple repos. You can mix-and-match any repos from Bitbucket and GitHub.

Installing and configuring new repos can be done in a snap now. When linking a new repo with JIRA, you’ll no longer have to configure brokers in Bitbucket or GitHub.

Get the DVCS Connector

Connect your source to your JIRA issues with the new JIRA DVCS Connector and let us know what you think.

Lets be honest, this blog should have happened a while ago and for that we say, thanks for your patience.

If you want to update your existing keys just hit the edit link and add your label.

The global site search, which can be focused with ‘/’, now has a repository autocomplete which will allow you to quickly find and then navigate to any repository you can see on Bitbucket.

Your repositories will be at the top, followed by repositories you have direct access to, followed by publicly visible repos.

If you know the repo you are looking for you can get to it quickly by typing parts of the owner’s username, followed by ‘/’ and then the repo name.

As you’d expect, selecting a repository from the autocomplete will take you to that repo’s overview page.

It’s no surprise, then, that all my READMEs on Bitbucket are written in Markdown (I favour the .text extension, but .md, .mkdn, and .markdown all work too). One thing I’ve wanted for a while is syntax highlighting of code blocks in READMEs. As of today, Bitbucket supports this feature, via Python-Markdown’s CodeHilite extension. Now, one can prefix a code block with :::javascript or :::python or whatever:

    :::coffeescript
    $('.label').each ->
      label = $ this
      label.css backgroundColor: sexyhex label.text()

Which produces something like:

Others won’t have had a chance to update their READMEs, so I’ll shamelessly plug a few projects which take advantage of this feature:

• sexyhex
• String::format
• jQuery.localize
• contenteditable

As developers, writing documentation is not necessarily one of our passions. But we all appreciate a good README when we come across one. Hopefully this small improvement will encourage some of us to give our neglected READMEs some love and attention.

Thanks for your patience as we work to improve Bitbucket’s reliability.

Update:

In preparing for this scheduled maintenance window, we made a backup of the switch config over tftp, which caused the switch to become unresponsive. We did a hard reset which restored service, and we’re now postponing the maintenance window until we understand the problem in full.  Our sincerest apologies for this unplanned downtime.

Bitbucket already supports fork-based pull requests, and while this model is great for open source projects – where new contributors can fork your repository and submit a pull request – it can feel heavy-handed when working in a small team.

Small (and large) teams rejoice! Today we are excited to announce the ability to create pull requests between branches. Using git’s lightweight branching support, and excellent extensions like Git Flow, have already made this the de facto workflow for Git diehards. We think that pull requests between branches is a perfect way to collaborate and conduct code reviews when working on a small or large team.

But wait, there’s more!

We’ve also streamlined some of the work around creating and updating pull requests:

• For those quick, one-commit pull requests, we’ll pre-populate the pull request title with your commit message so you can get your pull request started in just a couple clicks.
• For those times you realize your pull request isn’t quite ready for prime time, pull request creators can now undo their mistakes by rejecting their own pull request, rather than wait for someone else to do so.
• For the Git sorcerers among us, we’ve added smarts to detect when a pull request’s changes have been rebased.

Try it

First time creating a pull request? Check out this video and learn how to issue your first pull request.

A while back we blogged about Atlassian acquisition of SourceTree - Atlassian’s Mac client for Git and Mercurial distributed version control systems. Today we released version 1.3 of SourceTree and along with the release made a couple announcements – a new SourceTree blog, a revamped website and SourceTree is now FREE forever.

The Confluence team, at Atlassian, recently switched from Subversion to Git on Bitbucket using git svn – Stephan, a developer from the team who was responsible for making the switch, has taken the time to write up a blog detailing the tools and process used to make the switch from Subversion to Git.

Stephan says their goal was to “make the switch to a new version control system as smooth as possible for the team, without unnecessarily interrupting our development iterations.” We think he’s done a great job of detailing the steps many of us have, or will be taking as we migrate our existing Subversion repos to Git. Some of the topics he covers are:

• keeping commit authors the same between SVN to Git
• using svnsync to incrementally migrate developers and build servers
• pruning large files
• mapping tags and branches

The Crash

We determined the problem started with our syslog server crashing.  We found log rotation occurred at 04:05 as the cron.daily logrotate script ran:

-rw------- 1 root root 101714 Jan 5 04:05 messages-20120105.gz
-rw------- 1 root root 5012515 Jan 5 15:11 messages

Instead of responding to HUP with a graceful reload, rsyslogd completely stopped:

Jan 5 04:05:04 bitbucket04 rsyslogd: [origin software="rsyslogd" swVersion="4.6.2" x-pid="1905" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'restart'.
Jan 5 04:05:04 bitbucket04 kernel: Kernel logging (proc) stopped.

Based on previous log entries this is normal, but it typically restarts properly.  In this case, rsyslogd didn’t start back up at all.

We’re currently running rsyslog 4.6.2 that ships with RHEL 6.2.  We suspect we hit a known bug – the fix isn’t yet packaged for RHEL.

Blocking on syslog()

So we determined rsyslog crashed.  We wouldn’t have expected that to be much of a problem.  However, closer inspection shows we were syslogging over TCP.  Our syslog server was configured for both TCP and UDP:

$ModLoad imudp.so
$UDPServerRun 514

# Provides TCP syslog reception
$ModLoad imtcp.so
$InputTCPServerRun 514

But our clients were specifically configured to log over TCP – two @ signs prior to the hostname means use TCP and one would mean use UDP:

*.*    @@syslog.private.bitbucket.org

When our central rsyslog crashed all applications logging to it over TCP were blocked and our systems became unresponsive.  This included our custom applications and almost every other piece of our technology stack.  Unknown to us, we were  vulnerable to this problem since switching data centers over a year ago.  Moreover, recently we began syslogging much more information, such as Nginx logs.  In this instance, the crash together with the increased logging combined to make the situation much worse.

We’ve made these changes to ensure this doesn’t happen again:

• Disabled rsyslog’s HUPIsRestart option
• Added a Monit check to ensure rsyslog is restarted even if it crashes
• Switched from syslog over TCP to UDP

We’re sorry for the inconvenience this caused.  We’re always working to make Bitbucket more reliable and we won’t see this particular issue occur again.

Keyboard shortcuts provide a quick and easy way of navigating through Bitbucket and performing common (repetitive) actions without having to take your fingers off the keyboard. Pages you’ll find keyboard shortcuts useful for include:

• source code browser
• commit history
• pull requests
• searching from any page

Row highlighting

Press “j” and “k” to quickly move up and down between table rows and the source browser.

A yellow row highlighter is used when navigating tables and source to show you which row is selected, so you can quickly move between pages when pressing enter.

Shortcuts are just a key away

Navigate over to your Bitbucket repo and try out a few easy shortcuts to get going:

• Press “g” then “d” and you will quickly jump to your dashboard
• Press “/” to search your repo from any page

To see a list of all keyboard shortcuts, simply press the ‘?’ key from any page or read our keyboard shortcuts documentation and start using keyboard shortcuts today!