Current Articles | RSS Feed RSS Feed

The Compare Report for Git & Subversion

Posted by Titas Norkunas on Thu, Sep 26, 2013
  
  

We have improved the Compare Report for Continuous Agile use cases. The Compare Report can be found via the "Compare" subtab of you repository. It can show you recent changes (for instance, changes that you just released), or it can show you changes between two branches or forks (for instance, changes that you want to submit for merge).

Continuous Use Cases

In continuous workflows it is very common to use the master branch as the "production" branch. Here are three common actions that we recently made very easy to accomplish.

See what was recently released

If you are using tags, it’s very easy to see what your team has recently released - just click on recent tags and you will see what your team has merged to master recently. If you want to see a more fine grained view, go to the commits tab and scroll through the commits to find the one you want.

See released tickets easily

Protip: Select the most recent tag to see if your team is really following your process and keeping master in production (if they are, there should be no changes).

See released tickets:

You will also see a subtab that links to the affected tickets list. This can be used as automated release notes that show you what actually got out. Our CEO Andy loves this feature.

 

Create merge request after seeing changes:

Simply select your branch and a new merge request button will appear. If you want to create a merge request against master, just click “Create Merge Request”, fill in description and send the request!

We hope you like our freshly improved compare report. Let us know in the comments!

0 Comments Click here to read comments

Announcing Subversion 1.8 with Improved Merge

Posted by Andy Singleton on Thu, Jul 25, 2013
  
  

Assembla servers have been upgraded to Apache Subversion 1.8. This new release includes some new features and many improvements. The release notes are here: http://subversion.apache.org/docs/release-notes/1.8.html

You can download a new 1.8 client here

Subversion 1.8 makes big improvements in the merge operation. You don't have to figure out a long sequence of revisions and options. The merge operation will figure out the correct form of the merge. You will not have to track revision ranges, because the improved merge is much more likely to merge the changes that you want. You can update your working branch.

With the improved merge, you can use temporary branches and Assembla merge requests to review and accept code. You can put your changes into a temporary branch, and your operations to update the temporary branch and then merge it to trunk will work correctly. With the added quality from this code review, you can scale up your existing process to more team members. Your trunk will be cleaner, and you can run centralized continuous delivery.

Subversion 1.8 also tracks file and directory moves. In the past, when you move directories around to arrange your libraries and components, this often created a conflict with the central repository version. Now, your "update" after a move is much more likely to work correctly.

I want to give my thanks to Julian Foad and the rest of the Apache Subversiont team for taking up the request for improved Subversion merge, and making these improvements.

From the release notes: "Before using Subversion 1.8 with existing working copies, users will be required to run the svn upgrade command to upgrade working copy metadata to the new format. This command may take a while, and for some users, it may be more practical to simply checkout a new working copy."

Assembla is the world's best Subversion host. Learn more here.

0 Comments Click here to read comments

Calling All Hackers - Automate Git and SVN Workflows, Get Assembla For Free!

Posted by Michael Chletsos and Titas Norkunas on Fri, Jun 28, 2013
  
  

A Contest for Hackers

Recently we released an exciting feature, Server Side Hooks for our hosted Git and Subversion repositories. Today we present to you our first Community Contest - write Server Side Hooks to get Assembla for free.

What can You do with Server Side Hooks?

Anything. Automate your workflow - reject commits that you don’t like (no commit message? tests do not pass? does not comply with a coding standard?), trigger events on external services, rename branches... You know, it's software, anything is possible.

People have submitted two hooks so far:

  • A Subversion hook that validates php syntax. Install it and never see anyone committing non-working code again. Thanks Jakub!

  • A Git hook that validates the commit message based on a regex and rejects if it matches. It defaults to looking for “wip” in the message - any commit message containing text “wip” will not be accepted to the repository. Thanks Ido!

This is just the tip of an iceberg of what is possible. Go crazy!

How to participate

  1. Submit a server side hook for Git or Subversion via Merge Request to our hoook repository.
  2. Tweet it out - don’t forget to include @assembla and #serversidehooks
  3. When your hook is accepted and merged by our team, you win 25 Assembla subscription dollars, and your entered to win amazon gift cards that will be given out at random to participants.
  4. Submit as many hooks as you want.
  5. The Subversion and Git hook that is most installed in Commercial spaces at the end of the contest wins an additional 250 Assembla subscription dollars.

As more people submit hooks, we will unlock more prizes.

Submission and Review

Get submissions in by July 31, 2013 to be considered for the contest. We will make our final determination of winners on August 31, 2013. 

Read more about submitting hooks (and our review policy) on the hoook wiki. Refer to this list to see all the participants.

Have fun and good luck automating your workflows!

Need help?

Have questions? Contact us on our dev group.

5 Comments Click here to read comments

Something Cool with Hosted Repositories at Assembla is Happening

Posted by Michael Chletsos on Mon, May 13, 2013
  
  

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.

mpchlets@oberon  ~ tmp michaels space 021

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.

0 Comments Click here to read comments

Server Side Hooks on a SaaS repository? ✓

Posted by Michael Chletsos on Tue, May 07, 2013
  
  

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:

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.

0 Comments Click here to read comments

Access Control Lists for Your Subversion Repository

Posted by Titas Norkunas on Fri, Mar 29, 2013
  
  

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?

Protected Directories ACL Setup

Protected Directories

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.
What do you think, do you like this feature? Let us know in the comments!
Learn more about our Subversion features here

3 Comments Click here to read comments

Put Down Your Forks - Introducing Protected Branches

Posted by Titas Norkunas on Thu, Mar 21, 2013
  
  
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:

Protected Branches

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 Branch

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.

5 Comments Click here to read comments

Keep Your Codebase Maintainable - Introducing Inline Comments in Merge Requests

Posted by Titas Norkunas on Tue, Mar 19, 2013
  
  

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.

mr inline resized 600

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.


0 Comments Click here to read comments

Your Code: Accessible, Easy, Fast

Posted by Titas Norkunas on Fri, Mar 08, 2013
  
  

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

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
Understand your code’s history with Commits and Previous Versions

Commits / Previous Versions

  • Use Previous Versions to see commits affecting only a specific folder or file
  • Easily understand which tickets are affected by which commits
Keep your codebase sustainable with Inline Comments

Inline Comments

  • Discuss code on a specific commit
  • Mention people when replying to get the focus of that person right where you want it
We’re continuing to improve the Repository tool UI’s. You can read more about our Repository features here

Do you like what we’ve done so far? Let us know in the comments.

0 Comments Click here to read comments

Try the new Subversion code review and merge requests

Posted by Andy Singleton on Thu, Dec 13, 2012
  
  

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.

create merge requests resized 600

Contributions show up on the review list

mr list resized 600

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.

merge instructions resized 600

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

view diff resized 600

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.  Get it for free with Assembla Renzoku.

5 Comments Click here to read comments

All Posts | Next Page

Follow Assembla

twitter facebook youtube linkedin googleplus

Get Started

blog CTA button

Subscribe by Email

Your email: