Hoketronics - Mike Hochanadel » Revision Control

Subversion Install Swankiness Part 2

mike.hochanadel — Tue, 09 Dec 2008 00:16:37 +0000

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.

Subversion Install Swankiness Part I

mike.hochanadel — Sat, 08 Nov 2008 17:42:56 +0000

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 some research, I decided to follow the steps provided by How-To Geek. I updated my repository and installed Subversion. After the packages were downloaded, unpacked, and installed, I verified that it had indeed been setup on my system. Here's how it happened:

hokey@tardis:~$ sudo apt-get install subversion Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libneon26 libsvn1 Suggested packages: subversion-tools db4.4-util The following NEW packages will be installed: libneon26 libsvn1 subversion 0 upgraded, 3 newly installed, 0 to remove and 3 not upgraded. Need to get 964kB of archives. After unpacking 5128kB of additional disk space will be used. Do you want to continue [Y/n]?

hokey@tardis:~$ svn --version svn, version 1.4.4 (r25188) compiled Sep 28 2007, 10:50:44

The following repository access (RA) modules are available:

* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme

So after verification it was time to decide on where to create my new repository and setup web access. Now with anything Linux-wise, you are pretty much left to your own notions as to where to drop a directory for installs. Companies like Adobe use /opt for their application installs and some programs use /var to store data separate from program files. I figured /var/svn was reasonable enough so I had at it, creating the directory and using the Subversion command create to setup the files:

hokey@tardis:/var$ sudo mkdir svn

hokey@tardis:/var$ sudo svnadmin create /var/svn/

hokey@tardis:/var$ cd svn hokey@tardis:/var/svn$ ls -lat total 36 drwxr-xr-x 7 root root 4096 2008-11-07 17:54 . drwxr-xr-x 2 root root 4096 2008-11-07 17:54 conf drwxr-xr-x 2 root root 4096 2008-11-07 17:54 dav drwxr-sr-x 5 root root 4096 2008-11-07 17:54 db -r--r--r-- 1 root root 2 2008-11-07 17:54 format drwxr-xr-x 2 root root 4096 2008-11-07 17:54 hooks drwxr-xr-x 2 root root 4096 2008-11-07 17:54 locks -rw-r--r-- 1 root root 229 2008-11-07 17:54 README.txt drwxr-xr-x 15 root root 4096 2008-11-07 17:47 ..

Now that the repository was created, I needed to figure out how to get web access up. Welp, thanks to the How-To Geek and the original coders of the module, there was one available to tie it all together. Using libapache2_svn, a client can connect via Apache to a Subversion repository and write to it using DAV. This was a perfect setup, even though the security isn't the greatest, for me to develop locally before deploying my sites to my host. So here's how I did it:

hokey@tardis:/etc/apache2/mods-available$ sudo apt-get install libapache2-svn Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages: db4.4-util The following NEW packages will be installed: libapache2-svn 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 136kB of archives. After unpacking 344kB of additional disk space will be used. Get:1 http://us.archive.ubuntu.com gutsy/main libapache2-svn 1.4.4dfsg1-1ubuntu3 [136kB] Fetched 136kB in 1s (126kB/s) Selecting previously deselected package libapache2-svn. (Reading database ... 30761 files and directories currently installed.) Unpacking libapache2-svn (from .../libapache2-svn_1.4.4dfsg1-1ubuntu3_i386.deb) ... Setting up libapache2-svn (1.4.4dfsg1-1ubuntu3) ... Enabling dav as a dependency Module dav installed; run /etc/init.d/apache2 force-reload to enable. Module dav_svn installed; run /etc/init.d/apache2 force-reload to enable.

After I installed the module, I had to edit the dav_svn.conf file to point to my settings. Following the instructions, I removed the comments for configuration which included:

Setting the repository location:Location /var/svn
Uncommenting DAV svn
Setting the SVNPath: SVNPath /var/svn
And ucommenting the authority settings:
AuthType Basic AuthName "Subversion Repository" AuthUserFile XXXXXX Require valid-user

I then setup the authentication:
hokey@tardis:/etc/apache2/mods-enabled$sudo htpasswd -cm /etc/apache2/dav_svn.passwd hokey New password: Re-type new password: Adding password for user hokey

After doing a quick restart: hokey@tardis:/etc/apache2/mods-enabled$ sudo apache2ctl restart, I got this:

The wrong Location

What was wrong? I set the Location for Apache as /var/svn. What I was shooting for was to have /svn as the root. Doh! The SVNPath already tells Apache where to look for the repository. The Location tag and attribute in the configuration tell Apache where to display it on the web server. So I made the change and restarted. After testing authentication, I was ready to rock. Stay tuned for Part 2 of my swankiness as I look to integrate Subversion with a project and deploy it back to my host.