After finishing up the initial round of changes to davidseah.com by testing first on a staging server, I left Starbucks feeling productive and happy. When I got home, I thought of another tweak I could make, so I booted up the PC and made the adjustment. It was only afterwards that I noticed that I’d overwritten all the changes I’d made over the past four hours. I was livid.

As someone who makes a living doing digital media, I’ve learned how to manage my files in a certain way to avoid overwriting changes. My golden rule of thumb is NEVER WORK DIRECTLY ON THE SERVER, because what usually happens, inevitably, is that the master file gets overridden. So the way I work is to keep a master local copy and take period snapshots to a central server. This has been simplified greatly by adopting DropBox to synch all working copies across my Windows and Mac machines. Dropbox makes it possible to work on my master files from any computer, without having to manually copy the latest files to each computer.

Lately, I’ve been trying out MacOS X to see if it’s worth switching to. There’s some very cool software available for it, and one of the packages I’d been eyeing is Panic Software’s Coda web development editor. However, its paradigm appears to be “work on the server”, which is what I did. While Coda can save files locally, it isn’t designed to synchronize directories and files. Because file placement is so critical for web sites and web applications, it is kind of baffling to me that Coda has almost no support for maintaining the synchronization between local and remote sites. This makes me think it must be some philosophical stance the developer is taking regarding “work directly on your server” versus “develop locally and push your changes to the server”. Since I have enormous respect for Panic software, I’m presuming I am missing an important assumption on how to develop optimally with Coda.

I’ve had a couple of thoughts on this:

• Perhaps I should be using Subversion for version control
• Perhaps Coda developers are testing on their own local web servers instead of using a remote staging server.

In any case, there are some issues with workflow I need to figure out, because I hate losing work. HATE IT.

First Step

I already have a subversion repository on my server, but I use these primarily for Windows and Flash application development instead of for websites. I’ve never need to version the website work before because it was possible to work safe with my existing approach of “edit locally, push changes to server to view”, counting on DropBox to mirror my changes automatically and distribute them.

1. create svn repo for websites, using common credentials
2. upload working copy from Windows using TSVN
3. check out working copy using Coda

I downloaded an SVN cheatsheet. I had to remember a few things about the SVN setup. For my Media Temple (dv) running CentOS + Plesk, the svn setup is in /var/www/vhost/domain_name/conf/vhost.conf, and here I could find where the svn repo lived in the filesystem. All the configuration, including the user list and access control list (stored in /etc), are set up in the vhosts.conf. Adding a new repo was as easy as browsing to the repo folder and doing an svnadmin create name_of_repo. My credentials as administrator are already set up, though I could update the ACL to include other groups of users.

After this, I had to think of how to organize the repository. I thought briefly of putting all my web projects under one umbrella directory, moving it out of DropBox’s synched folder into a new SVN-synched folder. However, the problem is that commits to the repository would then be shared across all websites. So, if I did a commit to davidseah.com’s web files and the new revision # is 001, a commit to the completely-unrelated nonazon.com would result in a new revision # of 002. This makes it very difficult to keep track of what revision affected which site. So, that means that I really need to have a separate production repo for each website.

Secondly, I wasn’t sure that I wanted to version EVERYTHING. Really, I just need to version the parts of WordPress I’m working on (themes, plugins), and I don’t need to archive binary stuff. That said, I probably should go ahead and archive the key folders and files including the core wordpress files (might be helpful to detect hack attempts), and skip binary/image files and cache directories.

Gonna sleep on it.