Ariejan.net

If there’s more than one person working on a project, chances are (although slim) that at some point two developers work on the same piece of code and check it in. To clarify, let me give you an example.

The repository is currently at revision 5 and contains a file named ‘README’. Revision 5 of that file contains a single line: ‘This is a README file’.

Now, both you and your colleague check out r5 and edit README. Your colleague changes the line to ‘This is a documentation file’ and commits it back to the repository, which is bumped to revision 6.

You’re an island, and have no clue about the new revision being created. You just happily write away and change the README file to: ‘This is fun stuff!’.

When you commit your changes, you’ll get an error message:

4de122ba0f957e5faa2086d3be163c2b000

It’s been a while since I posted something new on the use of Subversion. I’ve been working with the tool a lot, and I’ve found that patches are a great way to communicate code changes.

For those of you who are still learning, let me first explain what a patch is. A patch is a text file that contains the alteration that were made to a specific file. It includes the lines that have been removed and the lines that have been added. In short, if you have a ruby script and edited it, you could create a patch file, containing the changes you’ve made.

Why is this useful? You could check in your changes to your repository directly. True, but there are cases that you don’t have write access to the repository. For example, if you wanted to contribute code changes to Acts As Exportable, you should create a new ticket and attach a patch file. I will then review your changes before I apply them to the code and commit them to the repository.

So, how do you go about creating a patch file and how do you later apply it to your source?

My articles about setting up a Ubuntu Development Server (part 1 and part 2) have been very successful.

I’m considering writing a new guide with more up-to-date information on how to setup a development server that allows you (and your team) to develop software, manage source code, track tickets and all that stuff.

After upgrading my Subversion server to Ubuntu Feisty, I noticed that when committing I got the following error:

svn: MERGE request failed on '/svn/repository/trunk'
svn: MERGE of '/svn/repository/trunk': 200 OK (http://svn.myserver.com)

Although the messages says that the commit failed, it has not. A simple ’svn update’ will merge the changes you made to the repository to your working copy again and you’re good to go.

You’ve been there. You have been developing in your trunk for a while and at revision 127 you get the feeling you’ve done it all wrong! The production server is humming away at revision 123 and that’s where you want to start out again. But how can you start again from revision 123? Easy as this with Subversion

I’ve just uploaded version 1.0.1 of the Subversion Cheat Sheet to Ariejan.net.

Please download this new version and get the following change:

• Fixed typo. Thanks to Gregory Gerard.

Head to the Subversion Cheat Sheet page now and download the new version.

The most common use of Subversion is to keep source code of applications versioned and secure. However, there are quite a few other options that are not so common at all.

Quickly read on and find out if maybe you can put Subversion to use in quite a few ways you didn’t expect.

I’ve noticed a huge interest in my Subversion articles lately and I thought to create a nice cheat sheet for all you.

The cheat sheets includes common commands that you’ll use when using Subversion on a daily basis. I didn’t include every option or command that subversion supports, nor did I include any administration stuff. This sheet is aimed at developers who use Subversion on a daily basis.

I often hear discussion about how often developers should commit their work to the central repository. Some say that you should only commit when you’re next ‘release’ is ready. Others say that you should commit every change you make in your code. There are even people who say you should commit your changes only at the end of the day.

All wrong! There is no such thing as ‘the way’, but there is a thing called best practice and that’s what I want to talk to you about. How often and what should you commit to your Subversion repository.

When created a TRY-branch a few days back to try some fancy new AJAX technology in my application. Not problems there, so now I want to merge the code in the branch with my trunk.

Since I’m a lone hacker, the trunk has not been touched since I created the branch. I have a checked-out working copy of the branch available.

Here’s a handy-dandy guide on how to merge your branch code with your trunk.