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.