Subversion is a version control system which makes tracking versions of files easy. This becomes essential when you are working with a group of people and want to make sure you are all editing the most up to date files. Subversion also allows you to get back to any previous version of a file, which means you can get to a backup file if needed.
This article assumes that a Subversion repository is setup for you, and you are expected to use it. Before we get started, you'll need a few details. They are:
- The URL to the repository
- The username and password to log into the repository
- Software to access the repository, specifically, Tortoise SVN. Grab it here
The person who created the repository should be able to provide you with the above info. Get that all together, and let's go to the next step.
Step 1: Checking out the files
Good news - you only have to do this step once, then you can forget about it. The way Subversion works is that you'll have your own copy of the project (the collection of files you're interested in). Suppose you have a developer and a designer working on a project - in theory, one needs only the code files and one needs only the design files. With Subversion, both individuals would check out the entire project. If you aren't used this, it might seem like a waste of space. Trust me, it's not.
Once the files are checked out, you can go to work. Any changes you make will remain local until you follow one of the steps below - so go ahead, make all the changes you want - they won't effect anyone (yet).
Step 2: Update files
Subversion works by having developers go through regular cycles of picking up files from the repository, making changes, and then committing them back. The cool part is that this process isn't synchronized - developers can check out and check in files at whatever pace they want (or the team decides on).
To use Subversion you just need to master the art of checking in and out files. The first process we'll talk about is picking up files -- known as updating.
By running a Subversion update, you are asking it to grab all the files that have changed since you last updated. Subversion will try to cleverly merge in any changes that have happened to the specific files you've worked on. If it fails, you'll end up with a conflict, and you'll need to manually sort out the mess. Regardless, Subversion will never remove or overwrite any work you've done - so it's always safe to do an update.
How often should you update? That depends - it can be anywhere from 10 times a day, to once a month. It depends on how active the project is and how quickly you want to incorporate other's changes.
Oh, and before you can commit anything to the repository you've got to be up to date. That's only fair, as your changes can't just work locally, but should work given the files in the current repository.
Step 3: Committing Files
At some point, you're no doubt going to be ready to check in your changes back tot he repository so that others can pick them up. This is known as committing.
Remember, until you commit files, your changes won't be visible to others. Also, you'll want to work out a clear set of rules when your team should commit files. Do you commit on a regular basis regardless of how working the code is? Or do you commit only after the code is 100% working and tested? Or something in between?
There's lots more useful things you can do with Subversion - like get diffs between the current files in your directory and those that have been checked in. Or find out which line of code was written by who (the so called blame feature). But, for starters, update and commit should be all you need. When you are ready, the whole story is here.
No go, develop in confidence. Know that your changes are both permanent and recallable. It's a good feeling, no?
Update: Looking for a Mac friendly solution? Check out SCPlugin. It appears to be just as easy to use as Tortoise SVN.