My Subversion and Dropbox Setup

I’ve really come to love my version control setup that I’ve been using heavily over the last several months, and I wanted to share it. It’s really quite simple and it has saved me a lot of headaches. I had been using a central, cloud-based storage method for uploading my working code (Google Docs, Dropbox, etc.) so that I had access to the code wherever I was and whatever device I happened to be using.

Here is the problem, though. For example, I’m coding on my desktop and am about ready to head out the door to continue coding at the coffee shop. So I zip up all of my files, upload them to the cloud, then download them to my notebook. That’s not too horrible of a process, but how do I fit version control into this scenario? My first try ended in more steps and more headaches as I could never keep the working copies and repositories in sync.

Then I heard of Dropbox’s synced folder feature. This was the answer. Now I don’t even move or package my files at all! I simply commit them to the repository. Here’s how it works.

First, I setup Dropbox with the synced folder feature enabled on all of the devices that I intend to use.

svn setup 01
Setup Dropbox on all devices

Any files I drop into any of these folders will automatically replicate to the other folders. Next, I setup a Subversion repository in the Dropbox folder of any one of the devices, which of course then replicates.

svn setup 02
Create a Subversion repository in any of the Dropbox folders

So here I am, back on the desktop. I checkout the latest version of the project code from the repository in the Dropbox folder, make my changes, then commit those changes back to the repository. The repository is now updated on all devices.

svn setup 03
Checkout a working copy, make changes and commit

On over to my laptop, let’s say I’ve already been working on the code from there as well. I perform a Subversion update on my working copy of the project, which grabs all of the changes I made on my desktop, then merges them into my local working copy. As usual, I make changes and commit back to the repository, and so on and so on.

One final note. It’s good to have that repository backed up, so on one of my devices, I have Amazon’s Jungle Disk installed, which backs up my Dropbox folder every night.

svn setup 04
Backup repository

So as you can see, once everything is set up, I simply hop on a device of my choice, update my working copy, make changes then commit back to the repository. Done. No headaches.

Cache Woes in Internet Explorer

I just finished troubleshooting one of my websites that was acting abnormally in Internet Explorer, and I have emerged from the battle, heavily scarred. Here is a snapshot of the files involved (the actual names of the files have been changed to protect the innocent):

File Diagram for IE Cache Issue
File Diagram for IE Cache Issue

It’s a simple setup. Index.php holds a form and is supported by a JavaScript file. The JavaScript file makes AJAX calls to serverSide.php, which in turn accesses a MySQL database. The JavaScript file then redirects the browser to secondPage.php and serves up the data.

The serverSide file is also accessed from secondPage through the JavaScript file. And therein lies the problem with Internet Explorer. Once index makes its call to serverSide, IE stores serverSide in its Temporary Internet Files folder. So when secondPage calls serverSide with new parameters, serverSide is retrieved from the cache folder instead of being called at the server and delivering fresh data to secondPage.

The solution was found in the php manual. There it gives the following information in the “header” article:

PHP scripts often generate dynamic content that must not be cached by the client browser or any proxy caches between the server and the client browser. Many proxies and clients can be forced to disable caching with:

<?php
header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date in the past
?>

I added this code to secondPage and sure enough, IE ignored the cached version of serverSide and served up fresh data.

I hope this information will save someone else from a massive headache.