My Transition to Subversion
Posted on July 20, 2006, under Development, Subversion.
So for my home office, I have always chosen Perforce for my source code control needs. But most recently I got a new laptop for work, and finally get a chance to experience how bad Perforce is in allowing you to work disconnected from the server. Over the years I have experienced my little frustrations with Perforce and had bee meaning to check out alternatives, but this was the last straw. It took me longer to get setup with Perforce on my new laptop, than it did to format and customize Windows to my liking.
So we move on; I have used CVS at past jobs, but never really liked it. I can’t put my finger on exactly what it was, but it just wasn’t intuitive to use. I figure an application has to be easy enough for anyone to get started, and then over time you can play with advance features and become an expert at it.
Subversion has been on my radar for a while now, of course never having the time to sit down and play with it. That’s kind of how my to do list has worked as of late, things only get done when they are an absolute necessity, all others wait their turn. So a quick Google for a tutorial on how to setup Subversion on a Windows server, lead me to this neat little project. From there setup was a breeze on the server side, took less than a minute. I then went on to choose my client, yes I choose a graphical user interface over being a command line guru. Seriously, mad props to those who can do this kind of stuff via command line, it’s on my to do list to become better at it. For now, I like the pretty.
SmartSVN was in my bookmarks because I used their SmartCVS client at my last job so I gave it a go. So about half way through importing my workspace, it complains that it ran out of memory. Ahh the one set back to Java, it didn’t have enough memory allocated to the JavaHeap. So I changed their config file, and tried again. Things progressed, it took a while to get half way through my workspace, and it crashed again. So once again bumping the config file up to almost 1GB of memory! However, this time when I started the application, it had to scan my current workspace which took about twelve minutes. Enough on this, I reinstalled the server just to get a clean start, and installed TortoiseSVN which is where I should have started at the beginning.
So after twenty four hours I can say I like it. My only little complaint is the “.svn” folders everywhere, which is similar to the “.cvs” folders from CVS. These tend to get in the way when you are packaging up install files and need to recursively load a directory. Or with websites and when you go to upload a webpage. However, a little ignore rule takes care of those problems, and all the benefits out-way that issue. I also must say, it’s fast. I know I am on a local network, but it seems to be hauling it’s little tail along.
So Subversion is my new source code control solution, I will come back and share my experiences again in a couple months. I hope things continue to go well.
Popularity: 6% [?]
6 Replies to "My Transition to Subversion"
mattrmiller on July 21, 2006
I know about this feature. However, I do not want to have to export the webpage or files necessary for an installer every time there is a released update. The ignore filters work for now, in the future I might have to end up going this route.
Jason on July 21, 2006
Although I totally agree that Perforce is only suitable for an always-connected environment, I am intruiged to hear that:
“It took me longer to get setup with Perforce on my new laptop”
Perforce setup is the simplest I have ever seen for an SCM, even without using the available Windows installer.
Having used both Perforce and Subversion quite a bit, I can assure you that Subversion is not all rosy. Despite addressing critical failings in CVS (such as non-atomic commits), the project appears to move quite slowly, and many other nice features in Perforce are missing. Particularaly annoying is the relatively weak merging support: I can’t believe in 2006 we are still meant to track which revisions we have merged manually! This is a fundamental aspect of source control.
mattrmiller on July 21, 2006
I did not word that correctly, setup was easy, but syncing my repositories was what took a long time. I am still trying to figure out why this is.
I appreciate you comments about the Subversion project, I was unaware of this information. I will have to look into this in more detail. I will have to setup a test server, now that I have my Subversion cranking I don’t want to risk messing this up.
Thanks for the feedback.
Jason on July 22, 2006
Ah, fair enough.
Back to Subversion, it is a decent improvement over CVS and does work well offline. For day to day use I am quite happy with it. Still, there are a bunch of other open source SCMs with more ambitious designs, and as they mature I would like to check them out. Or maybe by then the Subversion folks will get around to support for repeated merges…
Frederic Merizen on August 18, 2006
I use svk to address most of the shortcommings of subversion. It works as a svn client and turns subversion into a distributed source control system. What I like
- it integrates well with svn (if some users use the svn client and others use svk, that’s no problem at all)
- repeated merging is no problem (implemented with svn /properties/). Understandably but sadly, this only works if the last merge and the current merge were performed with svk (but it doesn”t need to be the same svk checkout)
- works offline like a dream thanks to it being distributed
What I don’t like
- the initial checkout takes long to complete (duplicates the repository)
- disk space overhead (duplicates the repository)



Nic on July 21, 2006
You can use the svn export command before packaging up files to geta copy of your source without revision control metadata (ie. the .svn folders)…