And this is a test of simile-timeline:

{bell tones wash over rooftops}

To make this recording, I recorded the ambient sounds of the neighborhood for a full day and edited them into overlapping “slices” of sound, one slice for each of the quarter-hour chimes (45 in all). The result is eleven hours of city sound smoothly compressed into about five minutes.

If you listen closely, you can hear every single one of the day’s bells (in all, 424 distinct strikes) in chronological order. Against this gentle textural backdrop, the sounds of city life ebb and flow: footsteps, voices, vehicles, birds, horns, jets, rain, thunder. Every now and then a brief lull in the bustle suggests a city pausing to take a breath. But the bells march on.

It’s good to live near bells like these. No matter how busy my day becomes, no matter how tangled up I get in the day’s affairs, whenever I remember to lift my attention and notice these chimes, I’m called back to the great mystery of Time. And for a fleeting moment, at least, the mind can stand still to savor something truly Timeless.

This is a Work of Art (2008) ~ laser print and ink on paperboard, with notary stamp and seal, 8.5″×14″

• It provides a seamless way for several people to collaborate on the same project without stepping on each other’s toes. (Have you ever had a collaborator delete one of your crucial files?)
• You can easily document the changes you make to your code.
• If you make a mistake, You can easily “roll back” to an earlier version.

Making the switch to Subversion is well worth the minimal effort required. (If I can do it, so can you.) This “Quickie” article will take you through (1) creating an online repository for your site; (2) creating a development site for doing live testing on your live server; and (3) using Subversion in routine development work. There are, doubtless, other, better, ways to accomplish all this, but this is what has worked for me.

Requirements

• Some basic grasp of what Subversion is, what it’s for, and (roughly) how to use it
• Subversion installed on your server and on your local computers
• A site (we’ll call it www.example.com) that’s already up and running on your Apache server. I’ll also assume your site lives in the server directory ~/example.com (i.e., in your home directory)
• You have login (shell) access to the server

Setup

For starters, you’ll need to create two new sub-domains. Follow your web host’s instructions about how to do that:

1. Create two new sub-domains: svn.example.com (for your svn repository) and dev.example.com (for your development site). [If you're using DreamHost, go to your webpanel and select Domains » Manage Domains » Add New Domain/Sub-Domain.] It’s a good idea to password-protect your dev site, so that only you and your co-developers have access to your not-quite-ready-for-prime-time version of the site.
2. Create a new Subversion project. We’ll give it the id “myproject”, and install it to the svn.example.com URL. (Don’t forget the username and password you choose here!) [If you're using DreamHost, you can create a new Subversion project right from your webpanel: select Goodies » Subversion.]

The rest of the setup happens through the login shell on your server. So log on to your server and do the following:

3. To hide the Subversion directories from web browsers, create (or edit) the .htaccess file in ~/dev.example.com. Add the following line:

   RedirectMatch 403 /\.svn.*$

4. Add this line also to the .htaccess file in ~/www.example.com.
5. Create an empty trunk/branch/tag directory structure as the initial import into the project. (In the following, “YOURNAME” is your svn username.)

   % cd
   % mkdir tmp
   % cd tmp
   % mkdir branches trunk tags
   % svn import . –username YOURNAME -m “initial import” \
   http://svn.example.com/myproject
   Authentication realm: <http://svn.example.com:80> My Project
   Password for ‘YOURNAME’: {enter password}
   Adding trunk
   Adding branches
   Adding tags
   Committed revision 1.
   % cd ..
   % /bin/rm -fr tmp

6. Now go ahead and import your current site (www.example.com) into the repository:

   % cd ~/www.example.com
   % svn import . –username YOURNAME -m “importing website” \
   http://svn.example.com/myproject/trunk

   If your site contains some dirs that you want to exclude from the development version (e.g., wordPress), you might prefer to import the site on a directory-by-directory basis:

   % cd ~/www.example.com
   % svn import ./keep_me1 –username YOURNAME \
   -m “importing keep_me1 directory” \
   http://svn.example.com/myproject/trunk/keep_me1
   % svn import ./keep_me2 –username YOURNAME \
   -m “importing keep_me2 directory” \
   http://svn.example.com/myproject/trunk/keep_me2

   Or, to be more efficient about it, you could run a little shell script like this:

   #!/bin/tcsh -f
   foreach d ( some_dir another_dir yet_another_dir ) {
   svn import $d –username YOURNAME -m “importing $d directory” \
   http://svn.example.com/myproject/trunk/${d}
   }

7. Checkout a working copy to the development site (dev.example.com):

   % svn co http://svn.example.com/myproject/trunk ~/dev.example.com

Your dev site (dev.example.com) now contains a full working copy of the latest revision of your site.

Routine workflow

1. Checkout a working copy from the repository to your local machine. (I recommend the svnX GUI client for the Mac.)
2. Develop and test your code, etc., on your local machine.
3. At logical stages (say, when you fix a bug or finish writing a new function), commit your changes to the repository. Some good habits to practice: (1) Always update your working copy before each commit. Always jot down a meaningful comment with each commit. (Instead of saying “Fixed a bug”, say “Fixed function Foo() in bar.php that had wrong mySQL query.”)
4. Log on to your server and update the development site:

   % svn up ~/dev.example.com

5. View the dev site. You may discover bugs on the dev site that weren’t apparent on your local machine. (They might be using different versions of Apache, PHP, mySQL, etc.) If there are bugs to be worked out, iron them out on your local working copy (i.e., go back to Step 2).
6. If you’re satisfied that your dev site is good to go, then either checkout a copy to your live deployment site:

   % svn co http://svn.example.com/myproject/trunk ~/www.example.com

   or update the copy already in your deployment site:

   % svn up ~/www.example.com

7. Double-check that the deployment site (http://www.example.com) is working to your satisfaction. If it’s not, go back to Step 2. If it is OK, you’re done!

The development cycle is now much simpler and safer. If you go on the road, just checkout a working copy onto your laptop, make your changes, and commit them back to the repository when you get the chance. If you (or your collaborator) made a mistake 6 revisions ago, just tell svn to checkout or update to an earlier revision.

Nice!

But eventually you may want to use server-side includes (SSI) to generate standard headers or footers on your pages. SSI are probably readily available on your webhost’s server, but to get them working on your Mac requires one small step: you have to configure Apache to activate a virtual server for each of your sites. Don’t panic; it’s easy to do.

Let’s say you have a site installed at ~yourname/Sites/project1. And let’s say the site’s pages have a standard footer, which is contained in the file ~yourname/Sites/project1/includes/footer.html. You’d like to be able to put the following SSI line in every file on your site:

<!–#include virtual=”/includes/footer.html” –>

Trouble is, the server interprets that path as relative to the DocumentRoot setting in your Apache configuration. On the Mac, the default setting (in /etc/httpd.conf) is

DocumentRoot “/Library/WebServer/Documents”

So when you load a page from the site, the server looks for your footer in /Library/WebServer/Documents/includes/footer.html. Since that’s not where your footer lives, you’ll probably just get this unhelpful error:

[an error occurred while processing this directive]

You could move your includes into /Library/WebServer/Documents, but that’s a supremely bad idea; you’ll soon go crazy keeping track of all your files scattered across the filesystem. Instead, take 2 minutes to do things properly, by setting up a virtual host on your Mac. This will allow you to set the DocumentRoot for each of your web projects. Here’s how:

1. Open Terminal and type: cd /etc/httpd/users.
   You should see a file in there with a name like yourname.conf where “yourname” is your Mac user name.
2. Type sudo vi yourname.conf and enter your password, if asked.
3. Insert the following lines at the end of the file

   NameVirtualHost 127.0.0.1:80
   <VirtualHost project1>
   ServerName project1
   DocumentRoot /Users/yourname/Sites/project1
   </VirtualHost>

   (If you have more sites, just add more <VirtualHost> blocks.)

4. Save and quit (type :wq)
5. Restart Apache: sudo apachectl graceful
6. Finally, edit your hosts file (sudo vi /etc/hosts) and insert the following lines at the end:

   127.0.0.1 project1

   (If you have more sites, just add more lines in that format. For example, 127.0.0.1 project2, etc.)

7. Now point your browser to http://project1 and your SSI include files will be correctly displayed.

It’s a few minutes before 9am on New Year’s day, and I’m standing on Day Street in Somerville, about halfway between Orchard Street (on my right) and the Davis Square post office (to my left). The post office is about a block away. There’s a Catholic church on Mass. Ave (to my right), a few blocks away that chimes the time every 15 minutes, starting at 9 am.

There’s a sweet spot right around here where you can hear the bells chime in one ear, followed by the echo off the post office in the other ear. It’s quite a wonderful sound. It’s quiet enough this morning that we may be able to catch it. So let’s just listen…

That’s it. Happy New Year!