Infrastructure Sunday

Infrastructure Sunday

I awoke with a brainstorm: I could use the simple template I’d made the “Cheap Websites II” project for the project itself. So I spent a couple hours tweaking it…eating my own dogfood, huzzah! While I was working with it, I also tweaked a few bugs that I wasn’t aware of, which never would have happened unless a user had brought it to my attention. I also am figuring out ways around CXTINY’s (the template) limited space, which will come in handy when handling user inquiries.

I had a second brainstorm too: that I really like analyzing things. If anything, I needed to add an “investigative design” section to the website. So I added one. And with this waking thought, I had the idea of modifying the version of “Cleanr” theme I’ve been hacking for the subsites to have an extended blog description, using code from CXTINY I’d written before. I haven’t gotten to that yet, but tonight before I hit the sack.

While all this brainstorming was going on, I was setting up Subversion (SVN) repositories on the server. I decided to move all the websites I’m working on into a new “projects synchronized/SVN” directory. I have been re-importing the directories and trying the integration features built-into Dreamweaver and Coda. The goal: source control that works cross-platform, with a minimum of fuss.

I had to make a few infrastructure decisions:

Decision 1: Although there is one SVN server, there are multiple SVN clients. Each SVN client potentially operates differently from each other, so I have to be a little careful about establishing some rules.

  • Each computer has its own local checked-own version that is no longer manually-synched by DropBox. I have to manually check-in and update, which is better for development purposes anyway.
  • On Windows, all website development is handled by the built-in Dreamweaver Subversion client TortoiseSVN (DW svn support is proving to be unreliable). All application development with Visual Studio will use TortoiseSVN or possibly a Visual Studio plug-in (Ankh, VisualSVN)
  • On Macintosh, all website development is handled by Coda’s built-in subversion client. All application development with XCode will use its built-in client.

Decision 2: My working source media files and documentation are kept in the DropBox folder. This is the way it worked before. What’s changed is that I’ve moved the website folders outside of DropBox, to be managed by SVN instead.

Decision 3: I’m not committing binary media to the SVN repositories, so these directories remain unversioned.

  • All graphic files, podcasts, PDFs, etc are not stored in SVN. Primarily because I am cheap with my server storage.
  • All graphics files, podcasts, PDFs, etc are still kept in the working copy’s folder; they just aren’t versioned. Theoretically the server itself has the master backup. As the server itself is backed up fairly regularly, I am not worrying about using SVN redundantly for media backup.
  • Any graphic files are stored in the regular project folder, exported to a local _export folder, and then copied to the working folders in SVN. This mirrors my usual deployment practice.
  • I’m not versioning any of the WordPress or Plugins other than my own original source code. These files are already backed up by the server, and I’m not modifying them. I may study them, but I don’t need to version them. Every time a WordPress update occurs on the server, I’d have to download everything and recommit. Pain in the butt. So not versioning WP files. My own themes and plugins, though, I am versioning.

I’ve been uploading and tweaking the repos for the past few hours, while doing other things like cleaning the house. It’s been a pretty productive day, though it looks like I’ll be up to 4AM again. Oh well!