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.
I’m still working with what to bang out here at hoketronics.net. Long term wise, I’m looking to integrate some social media profiles I have floating around in the name of consolidation. Also, I’ll look into implementing Open ID using hopefully some WordPress plugin magic. The content needs to be filled in as well. Look for some pages to crop up. Also, I’ll be testing out designs on the fly so if it breaks, please be patient, it will be all good real soon. But that’s for this site.
I’m working on another site, http://www.kccollegegameday.com, to help show my love for college football. I first turned it out last year when a friend of mine and myself needed a reason to go watch college football every week out at some sports bar establishment. That idea quickly turned into a website. By mean quickly, I mean I hit up GoDaddy, registered the name, did the one click install from their scripting site, setup emails/accounts, searched and installed a free template, and blasted out an announcement. The site could use some refreshing almost as bad as this one does.
Really, it’s just minor ticks that need improved. I really dig the color scheme but some of the style is just not lining up correctly. A great example is the bullet points. If a big point lands, it will center in the middle and look off. Chances are I’m going to customize the current template, much like this open source base one here. So look for some additions at that. There’s also some rotating image header script that’s piquing my interest.
Backend wise, I mentioned that it was a one click WordPress install. Welp, working with the new release here, I’ve decided to begin work on upgrading WordPress on KCCGD. Right now, I’m weighing two options. First, I can roll out the complete package and run an update script to bring the old database/code up to the current release. Or I can research about using one instance of code for multiple blogs. I haven’t figured out which one, but will talk about the decision and experience soon.
All of this work needs to be tracked and I’m in the middle of getting back into habit of revision control. I used CVS way back in the day at one of my K-State jobs and have heard of Git, Subversion, and Mercurial. I’ve used Git in a limited fashion at work for some Python projects, but have yet to taste Subversion or Mercurial. More than likely, I’ll be doing something other than Git as a reason to learn new software. What is the best version control software for websites? Maybe the first step is to see what WordPress uses for their version control. At any rate, I’ll be talking about what route I go with that in the near future. Until then, check out KC College Gameday and let me know what you think.