Nothing Like A Fresh Subversion Import

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.

The first step in molding the fresh install of Subversion into something workable, was to decide on what kind of structure I wanted to keep.  Articles online discussed whether or not to keep multiple repositories for projects or maintain a single repository to house multiple projects.  In thinking of how I wanted it implemented, the simplicity of maintaining a single repository won over the cleanliness of revision management in multiple repositories.  Perhaps at a later date I can split it out or even incorporate Git, but for the purpose of getting started I'm going with one repository.

I decided to follow the svnbook's advice of a creating a temporary directory structure to setup the initial framework of the repository.  In my case, there are three major areas I will develop in:  websites, scripts, and home related projects.  I created the structure and imported them in to Subversion using the svn import command.  After which, I deleted the temp directories and verified the structure below.  Here's the output:

hokey@tardis:~/tempdir$ sudo svn import . file:///var/svn/ --message 'Initial Repository Layout'
[sudo] password for hokey:
Adding         scripts
Adding         headquarters
Adding         web
Adding         web/gonzoguys.com
Adding         web/gonzoguys.com/trunk
Adding         web/gonzoguys.com/branches
Adding         web/gonzoguys.com/tags
Adding         web/h0key.net
Adding         web/h0key.net/trunk
Adding         web/h0key.net/branches
Adding         web/h0key.net/tags
Adding         web/hoketronics.net
Adding         web/hoketronics.net/trunk
Adding         web/hoketronics.net/branches
Adding         web/hoketronics.net/tags
Adding         web/kccollegegameday.com
Adding         web/kccollegegameday.com/trunk
Adding         web/kccollegegameday.com/branches
Adding         web/kccollegegameday.com/tags

Committed revision 1.
hokey@tardis:~/tempdir$ svn list --verbose file:///var/svn
1 root                  Nov 18 08:44 headquarters/
1 root                  Nov 18 08:44 scripts/
1 root                  Nov 18 08:44 web/
hokey@tardis:~/tempdir$

It was time to work with local install of my website.  I copied the production code to my home folder on my local webserver.  After setting up the database and changing root path directives, I set about verifying the local page.   It looked good so I then downloaded the latest WordPress package.  Following the directions, I copied the updated code and again verified the website.  The recent point releases didn't affect the database schema, so I was good on that end.

Now that I updated my code to the latest WordPress point release, I imported the website into the Subversion repository.  Using svn add, I recursively added all of the new files from my website.  When it successfully added the file set, I committed the change using svn commit, complete with the initial import message.  Subversion pulls from CVS alot and these two commands reflect that.  It almost felt like I was greasing the code revision bicycle gears and getting back to the smooth ride of code management.

So now that I added the website files to the repository, I did it twice because of another point release in WordPress, it was time to test and deploy the code.  Using the svn export command, I copied the code to the web docs directory on my local webserver.  I decided on doing that instead of checking out the repository on the live site because I'm on a shared hosting platform for production and I didn't want trailing '.svn' folders eating up space.  Plus it adds the benefit of greater security.

hokey@tardis:/var/www/hoketronics.net$ sudo svn export http://localhost/svn/web/hoketronics.net/trunk ./hoketronics.net

The code exported to the local server.  This is where I ran into some issues.  The code portion of the website works well in different directories, but I need to come up with a way to manage dev/test/prod databases for link resolution.  The logon screen for the local test install pointed to the local dev install.  Regardless of that little issue, the code tested out well.  Now it was time to deploy the website to my shared host, minus the config file.

The other issue I ran into was the process of updating my shared host with the new code.  I run Linux on the webserver locally but my workstation runs Windows XP.  The best way, I thought at the time, to copy the update was to compress the test folder, copy it to my workstation, and then use Filezilla to copy it up to my shared host.  This proved laborious and it ended up taking more time than I expected due to two reasons: remembering the correct compression one liner and not taking advantage of a command line ftp client on the local webserver.

That said, the production site on the shared host updated with no breaks.  I logged on, verified the version, and inspected both the UI and and the backend files for any issues.  The Subversion process was almost complete.  After I updated the code, I made note to change the initial work flow for updating my site to handle updates from the local webserver to the shared host.  Also, I'll take some time to flesh out different configs for my environments to avoid any path issues the next time around.  Lastly, I'm going to make sure I centralize my one liners for easier access, maybe even using the repository to keep track of additions.

Subversion seems like a great centralized source code management tool.  With my CVS experience under the belt, much of the commands feel familiar and comforting when I invoke them.  Now that I have the repository live, kccollegegameday.com is getting some work.  I'm looking forward to checking the 'diffs' when modifying pages and themes.  Chances are you'll see me talk about that on top of a couple of article ideas due to the roadblocks experienced with this project.

So Wednesday I scrolled through the Google Reader roll and I found out, thanks to OStatic, that the Theora video codec reached the 1.0 release.  What is Theora?  It's part of the same community at Xiph.org that hosts the the Vorbis codec for audio.  What is Vorbis?  It's a completely open source audio compression technology brought up in response to Fraunhofer Gesellschaft's announcement of charging for the license of the MP3 codec.  So Theora follows in that same tradition and is a completely open sourced video codec.

Usually when projects from work come down my pike, I use ffmpeg to transcode video between formats.  I don't get that much exposure to the high powered equipment that the producers use to export video.  But when some deadlines must be met, I usually get the task of taking some media, whether it's from Beta, DVD, or others, and spitting it out to their requirements.

The two machines that compete for my time is a Windows 2000 workstation and a build of Ubuntu Studio Linux.  The nice thing about the W2k build is that I can capture video from Beta with relative ease.  For moving media around bitwise, the Linux build with ffmpeg works out way better.  Batch processing on the Linux machine makes it a snap to script up custom projects and let them roll.  What I haven't had to opportunity to do is to work with Theora.

Theora and Vorbis haven't had the kind of uptake MP3 has had in the media arena, mainly due to being late in the game.  When I take on projects, I'll still probably stick with ffmpeg.  My interest is piqueued however, and I may just drop in the new 1.0 release of Theora to see if I can gain any improvements compared to my other methods of turning out video.  That's the great thing about open source, you're free to work with and it gives you room for improvement for a low cost.

Before I rolled out the relaunch, I spent a good month trying to figure out the right kind of development environment for tools the I had available.  I have three laptops but all of the batteries are toast and the motherboard on one of them has gone the way of the dodo.  I convinced myself to develop exclusively off of a big ole Western Digital 80 GB Passport USB external drive.  First step done.  After doing some research I decided on XAMMP to drive my environment.  It was nice but there were some issues.

My real focus for this development environment setup was to be able to plug in the hard drive and code directly off of it.  I work off of multiple platforms at home and at the office.  Almost all of the apps do not have a single application to launch.  I already run some portable apps that support clients in Windows, Mac, and Linux flavors, like KeePass.  XAMMP advertised clients for each platform so I decided to give it a try.

XAMMP is a fully integrated web application development server.  The purpose of XAMMP is to roll out a fully workable, out of the box *AMP stack.  The packages include an Apache2 server, PHP version 4 or 5, MySQL 5, and a torrent of management utilities and open soruce libraries/modules.  There are some differences between platforms for the package set, however.  The beauty behind it is that you can pick and choose what you want and start work within minutes.

At first, I wanted to setup all of the platform packages on the flash drive.  Due to the desire for cleanliness on the drive, however, I tried to install the software locally on all of my workstations.  Most of my time is spent on these machines anyway.  Linux was the easiest to turn out, mainly because it just dropped everything into the '/opt' directory.  I could change the doc and database links and move forward from there.  Windows was also a snap as I could modify configuration and turn services on and off with the included XAMMP control panel.  The Mac OS X client was not so easy.

The installer package for the Mac does not allow for choice.  It scans you computer to see if it's okay to run on and then drops it straight to the Applications folder.  The folder it installs to is not entirely encapsulated.  When the configuration points to the database files on the flash drive,  the service will crash upon startup.  I've already been exposed to issues on lock file management on Mac OS X Server, and the workaround didn't work for this issue.  The Apple puts the lock file in a directory other than the MySQL default setup.  When I symbolically linked the lock file, the database would start up.  This was not working with XAMMP.

After spending some small time here and there for about two weeks on it, I ended up just letting it go.  Attempts to find out on their forums page led me nowhere.  Also in my research on this topic, I discovered a Portable Apps version of Xammp but it is Windows only.  Not much help there.  Maybe one day the devs on the project will look for better portable support.  Until then, I'm focusing on version management and working off my lil server in my apartment.

I'm still coming to terms with getting distracted on small setup roadblocks.  I really didn't need to waste the time figuring this out when what I really needed to do was to turn out this blog and other projects.  Struggling with Xammp taught me that sometimes the perfect environment will trickle down from actually working on things first rather than focusing on a perfect setup for work that hasn't started yet.  Plus it's alot more fun when you actually have projects in progress instead of dreaming of working on projects.