We announced our latest feature Server Side Hooks the other day. But before we even did that, something very cool happened, we got our first hook submitted by a contributor outside of Assembla. Thanks so much Jakub.  Now users with Subversion repositories can install this hook and check their PHP code syntax.

We could never have had the time to think of creating nor actually implementing a solution for checking PHP code, because we would want to check all sorts of style of code and the scope would grow. Now users can scratch their own itch with minimal effort on our part.

For those of you still not sure what I am talking about: We are allowing customers to write their own Server Side Hooks and install them on our Servers, that’s right, you can extend Assembla’s cloud repository offering.

Thanks again and keep those hooks coming.

Oh BTW, you can have Server Side Hooks in a SaaS Repository.

Cloud repository hosts have failed us. The power of hosting your repository locally is the ability to implement Server Side Hooks. These hooks allow you to control your repository and the source code contained within.  Its super convenient for an organization with many contributors to a single repository. You can syntax check code, ensure commit messages are proper, add the power of automation or anything else you need your repository to do better than if you were relying on external webhooks.

To add a Server Side Hook in your current Assembla Repository - go to the Settings Page -> Server-Side Hooks:

• Git: pre-receive, post-receive and update hooks

• SVN: pre-commit, post-commit, pre-revprop-change and post-revprop-change hooks

• Community Supported: Submit your own hooks or partake in the fruits of another’s labor

• Prevent commits that do not comply with your Coding Standards

• Validate commit messages for status updates and valid ticket reference

• Create Workflows with specific status and ticket changes or kick off external procs

We are very excited about Server Side Hooks and hope that you find them as useful as we do. Take a look at some of our other available Repository Features

We are happy to announce that we have implemented an Access Control List (ACL) for Subversion directories. ACL workflow allows you to restrict directories so that only certain developers have write permission. This workflow can be enabled at critical times like when there is a feature freeze, or to protect sensitive areas of an application.

Those of you who store multiple projects in a single Subversion repository can now easily configure permissions for your project teams on the directory level. But enough talking, if there isn't a screenshot it didn't happen, right?

So how does it work?

• Specify users who will be able to write to certain directories - they will be the owners of that code
• Everyone else will be able to see, but if they want to contribute, they will have to send a merge request
• Directories a person is not allowed to write to are marked with a red lock icon.
• Directories that a person is an owner of are marked with a green lock icon.

Lets talk about forks. They are so awesome for open source. Why?

• A fork is a natural way to give external contributors a place to work
• Really, that is the main reason to fork

Look at the open source projects more closely. Only the external contributors - who are not part of the core team - work in forks. The core team members work with the main repository in branches.

A company does allow their developers to commit to the repository. A company does not want everyone to be able to merge to a release or master branch, using a fork for this is an over-complicated workaround:

• Developers need to maintain forks
• Additional setup to CI is required
• Whenever a change to the repository configuration is made, it needs to be made in all forks (for instance installing a webhook)

Does it have to be so difficult? Not at all. Here is where Protected Branches are awesome and a clean solution to this problem.

A Protected Branch is a branch with limited write access. Specify members (or groups) of your team that will be able to submit code to a branch:

Now, only these people will be able to push to the Master branch. Everyone else will have to contribute code through merge requests. They will be able to push to any other branch in the repo, but not Master.

Protected Branches enable various common techniques - mandatory review from a senior developer, release manager that maintains release branches, feature freeze a release candidate. We have no doubt you will find even more use for it.

Sometimes you just have to leave that Social Coding aside and get some work done.

Code Review is an essential practice for teams that want to have a Maintainable Codebase. Some teams go as far as instituting peer programming, where two developers to work on a single computer on a single piece of code. However, most of us don't have this luxury. For everyone else, we present lightweight Merge Request reviews with inline comments.

Today, after much experimentation and input from customers like you we are ready to release the fruits of our labor. Merge Request now include inline comments. Thanks go to Kivanio Barbosa and Ghislaine Guerin for their contributions.

Includes, but not limited to:

• Add Inline Comment by clicking the green comment icon

• See who participates in the discussion on a specific version of a file

• Mention people when replying - bring their attention to your Inline Comment

• Enable Code Review notifications in stream to get emails about comments

We are listening to your feedback. Let us know how we can improve Merge Requests to suit your needs.

Learn more about Assembla Repository features here.

We haven’t been blogging for a while, but that does not mean we haven’t been busy. As you have seen, one of the things we have been working on is rethinking how code is browsed and how to improve the experience for both developers and other team members.

Dig into your code with the redesigned Code Browser

• Browse the code faster with our ajax implementation of the source view
• Merge request, fork (Git-only) and compare controls are easier to find and use

Your Source/SVN tool now supports a modern code review and code contribution process. You can see it under the new "Review code" subtab.  It is similar to the workflows enjoyed by git users to include a large number of contributors or to review code for continuous integration and continuous delivery.  You can put your changes in a branch, review them, and merge them through a Web-based UI.

This first release has a simple workflow that requires users to manage their own branches.  Please leave a comment with your feedback.  After we are sure that this is working smoothly, we will enhance it with much-requested features like extra permissions on trunk (to push contributions into reviewed branches), one-button branch creation, and inline code commenting.

How it Works:

Make a temporary branch.  Write your changes and commit them.

Make a merge request.  You only need to select the source branch. We already know how to merge it to the destination it was branched from.

Contributions show up on the review list

Select a merge request to review.  You can open the "Get Changes" link to see instructions for merging and testing the changes.  In most cases, you want to test the result of merging the change with trunk (or the source that you branched from).  So, the instructions will ask you to switch to trunk, and merge the changes.

Use the controls on the merge request to write comments (you can @mention the contributor), vote, and view changed files and diffs.

Subversion merge requests have a lot of the same great features that are in our git merge requests.  For example, they get linked to tickets when you include a #ticket link in your commits.  So, when you can see the status of the relevant code changes.  And, when you look at a merge request, you can see the tickets you are working on.

Patch or branch?

A lot of Subversion code review systems use patches.  You make a patch (a diff file with the changes) and you upload it to a code review system like Reviewboard, or you email it to a list of reviewers (Subversion developers do this on the Apache Subversion developers list).  The advantage of a patch is that it is easy for a reviewer to apply it to whatever version of code he is working on, and it doesn't need to be integrated with your repository server.  However, it is annoying to make and upload a patch, and you can't fix it.  If you see a problem in a branch, you just switch to the branch and fix it.  We discussed this with our own team, and with some of the Apache Subversion core developers, and we decided that we prefer reviewing and sharing real branches.

We hope that you see some benefit in the branch-based workflow.  Leave us your comments.

On November 15, Assembla and WANdisco presented a webinar Beyond Scrum: Scaling Agile with Continuous Delivery and Subversion. For those that did not get a chance to register or attend, the video and slides are below. Enjoy. 

 

View and download the slides

In this 30-minute webinar Andy Singleton of Assembla and Scott Rudenstein of WANdisco described how to go beyond traditional Scrum principles and scale to globally distributed teams with continuous delivery and Subversion.

They discussed how to:

• Achieve continuous delivery using branch, merge and code review techniques.
• Accelerate the work and coordination of multiple distributed teams without lengthy meetings.
• Improve performance and security management, while replicating real-time repositories, within a centrally-managed Subversion infrastructure.

 Other Releated Resources from our Blog:

• Build your Assembla Merge Requests Gangn..Err Gerrit style with Jenkins
• Take Control with the Continuous Delivery Dial
• The Three Agile Use Cases: Where Do You Fit In?
• Beyond Scrum Roadmap
• Avoiding Premature Integration or: How we learned to stop worrying and ship software every day
• Intro to Scalable Agile: Scale Your Teams and Release More Frequently
• Continuous Delivery and Scalable Agile - Find Out the Secret

At Assembla, we have been converting our apps over to Ruby 1.9.3 from 1.8.7.  We had the GC patches applied to 1.8.7 and were in no hurry to switch to 1.9.3 (See graph below).  One of our applications relied on Ruby SVN bindings, but the current Subversion project only supported Ruby 1.8.x. 

Well with a little patch and some cooperation of the Subversion Team, we got it into trunk.

Ruby 1.9.3 has initial support in Subversion development branch now.  The tests still need some work, but overall its nice to have it finally.

A special thanks to Vincent Batts who did the original work on the patch and the bulk of the effort.  Thank you Philip Martin from the Subversion Team for working with us to get this patch accepted.

 

On November 15, Assembla and WANdisco are presenting a webinar: 

Beyond Scrum: Scaling Agile with Continuous Delivery and Subversion

Andy Singleton of Assembla and Scott Rudenstein of WANdisco will describe how to go beyond traditional Scrum principles and scale to globally distributed teams with continuous delivery and Subversion.

In this 30-minute webinar you’ll learn how to:

• Achieve continuous delivery using branch, merge and code review techniques.
• Accelerate the work and coordination of multiple distributed teams without lengthy meetings.
• Improve performance and security management, while replicating real-time repositories, within a centrally-managed Subversion infrastructure.

Thursday, November 15th at 20:00 CEST | 2:00 pm EST | 1:00 CST | noon MST | 11:00 PST | 19:00 UTC