Welcome back to part 2 of my Subversion install series. What we are going to go over is developing the right structure for the repository, importing a website, updating a website, then testing and deploying the website using some of Subversion’s command sets. There were some road blocks along the way and I will talk about that as well as some other thoughts about the process. After that I’ll talk about what’s next but first let’s setup and deploy some code.
Here we go with the newly decided first part of my Subversion install series. I decided to break it up into smaller chunks of articles as the first part really is the installation/setup part and the second is the integration/deploying part. So with this first part we’re gonna talk about downloading, verification, repository setup, and Apache integration. I’ll make it short and sweet as possible but grab a cup of joe so we can get started.
When figuring out how I should download Subversion, I weighed many options. I could either grab the source from their website at Tigris or install from Ubuntu’s repository. The hardcore geek in me wanted to compile from source, but I really wanted to roll out the software quick so I can focus on the blog code. Also updates trickle down from Ubuntu with relative automation, so I went with acquiring the binary from Ubuntu. It really makes sense to knock out the binaries for tools surrounding a project and focus on source for project related code. Why waste your time setting up a utility when it’s the poject you should be working on?
After working through the development environment portability debacle and relaunching the website, it was time to figure out how to control the customizations I have planned. There are big plans coming for the site and I want to template the changes for future identity management and blogging prospects. I really didn’t set much time on setting up a system by myself. Time for me to re-introduce myself to revision control.
Revision control is the de facto standard way to manage code changes and bug fixes in a project. From a single developer to a collaborative work environment, it’s the best way to keep the evolution of a project in steady hands. With a little effort in between building the project, you can roll back, trace history, and work on new features without affecting the production code. For what I have planned, I need this kind of system to handle the changes heading toward this current deployment of the WordPress blogging software package.
My first exposure to revision control started way back in college. My role as a student worker included modifying the content management portion of the college’s in house online course delivery system. We used CVS as the motor for our revision control. CVS was by all means not perfect and we had workarounds or hacks to help push projects along, but it was way better than nothing. A couple of years ago, I felt the need to retrain myself on that but ended up deciding on Subversion as it was an evolution of the CVS mindset. What ended up happening was a huge distraction of data backups and an implementation of rsync at headquarters.
Before deciding on what software to use, I felt the need to research the topic of revision control to see what changes came about in the last couple of years. Due diligence is always near and dear to my heart. I looked at lists of many different types of software. There was a CVS control system guideline for websites that cnetnews.com follows. Git was another up and coming software package that Linus Torvalds built which I used on a project at work. And a Django module strictly developed for website control and rollback also came up in my searches.
After looking over the choices Sunday evening, I decided to go with Subversion. The biggest factor that won me over the other methods was the WordPress development team’s use of Subversion. Another big factor was my previous desire to use Subversion. What I hope to gain is learning how to use a web server to update and manage code remotely. This also opens the door for me to try out different IDE’s because of plugin or internal support for Subversion. Finally, further down the road I want to bang out some code for Songbird and they use a documentation/wiki/code repository framework called TRAC, which uses Subversion for its repository portion.
So this week I’ll start figuring out how to implement Subversion on the website. I’m not sure how long it will take, but I will report or update on its progress when necessary. Once I nail down the process for code management, I’ll finally get to work on updating WordPress for kccollegegameday.com. Until then, I’ll pop in and out to pontificate when the urge fills me.