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.
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.
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.
What should, according to you, be included in this guide? Please let me know! Just leave a comment and I’ll pick it up.
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.
So, what is the problem here?
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:
svn merge -rHEAD:123 . This will see what changes you’ve made since r123 up until now (r127 in your case) and ‘undo’ them.
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.