Wiebo de Wit's thoughts about game development and more…
Tag Archives: SVN
As you may have read (or not) I lost the source code of some past projects. Keeping your code on your own machine and doing your own backups is all good and if you have that in place that’s cool. It’s no insurance against dropping drives from the stairs though. I started thinking, and the idea of having a server which holds my code safe for me started to sound pretty handy. That and being able to reach it from anywhere.So I went looking. It turns out you basically can do three things with SVN:
- Create your own SVN server, and host the repository on that. You can install a server, or: Assembla offers a complete Vmware virtual machine (appliance) which you can run on your VMware hypervisor at home.
- Create a local repository on your development machine, or shared folder on the network.
- Use a hosted SVN repository.
Creating your own server is interesting, but I don’t want to have machines running when I’m not using them. So that’s not an option.
The documentation of most (if not all) SVN clients tells me that it is not a good idea to put your repository on a network folder. I actually tried to create a repository on my network SMB drive but it just won’t work. The thing is formatted with FAT32 and I get permission errors which I cannot fix right now. A local repository on my development machine is the other option, and it has the benefit of me having versioning, but it does not address the need of a separate place to store source code. I could put a scheduled task on my machine to copy the files from time to time, but it feels clunky.
It feels weird to put source on a site somewhere, but hey, let’s look at the hosted options:
- Google: free hosting for public, open source projects.
- Assembla: only hosts public projects with the free version
- XP-Dev: free hosting, private projects.
There are more hosted solutions, but XP-Dev seems to be the one to go for now. The big advantage of a hosted repository is that you can access your sources from anywhere. Also, it adds additional functionality like bug tracking. Commitment to a solution is a big thing, but as XP-Dev allows export of your repository at any time, you can get your data and version history and implement it somewhere else if you want to.
So, I went there, registered, created a repository, and now, which client to use? Lets look at the options:
- subversion: the command line tools.
- RapidSVN: graphical interface.
- TurtoiseSVN: graphical interface, with shell integration.
Again, there are more options but these represent the most different in features and functionality. The command line tools will do the trick, but I need something more visual. I prefer to use TurtoiseSVN. The added benefit of shell integration is that I can ‘see’ if my files are in sync with the repository or not. And if not, all I have to do is right-click and select Commit. No need for a repository browser or command line tools. Also, the ability to exclude files from the commit is nice.
I’m satisfied with this solution, and so far XP-Dev and TurtoiseSVN seem to offer all I need.