Protect Your Most Valuable Asset

If you own a house, most likely you have insurance in the event of a disaster.  You might even have a safe box somewhere in your house to protect your valuable objects and you might even have a safety deposit box at the local bank to protect your most valuable items.  Why do many developers not use a Source Code and Version Control System for their source code? After all, your source code is the most important business asset you have and until you hand it over to the client it’s yours to protect. Even if it’s your personal code, why not protect it?

Real Studio doesn’t make this easy, in my opinion, with their binary (rbp) file format. The binary format is very fast and very portable single file in comparison to the version control (vcp) file format that creates a text file for each object in your project. The binary format, in my opinion, gives users a false sense of security. Bugs happen and hard drives fail.

Version control systems can not read the binary format and track code changes. They check in a binary file as a whole unit regardless of how many Real Studio objects are in it. So it doesn’t matter if the code in Window1 has been changed or not because all that code gets sucked into the server.

In my ideal world I’d love to have a format that works with the source code systems but is also as easy to package up and move around as the binary format. Apple’s bundle format would be ideal but as far as I know there is nothing built-in to Microsoft or Linux distro’s that does this automagically.

Subversion servers (and their like) tracks source code changes down to the line of code. Change the capitalization on an RB keyword in Window1.open event? It’s a change that’s noted in the object file (window1) and even to the line of code. When you check in the changes to the server it knows who did it and assigns a version to it.

We’ve used a variety of systems over the years. Many years ago we used Visual Source Safe, CVS, and we currently use Subversion. There are a lot of developers that are using GitHub with a lot of success. Regardless of what you use I believe you should be using some form of source code and version control system. It’s the smart thing to do as it’s the only safe way to store your source code.

Have you every lost code because you failed to keep a copy of it, deleted it accidentally, your hard drive failed, or your computer was stolen? There’s nothing worse than knowing you had some source code that you can no longer find and use. That’s an asset that you’ve now lost – forever.

I know I’m not the only developer that’s worked on a piece of code for a few hours only to realize that it’s crap and I have to revert to the pristine version (because it’s impossible to undo all the changes you’ve just made). You can do this with the binary format if you are really, really good (or paranoid) about making copies of your project but that’s a lot of work. The source code and version control systems are designed for this!

These systems let me save incremental changes, create snapshot copies of the entire project and even compare files across versions so that I can see exactly what’s changed. With multiple developers on a project this is nice to see who changed what and when. When the developer commits a change we all add a note on what we were working on. This is important for us on large projects.

These systems just aren’t for teams, though. Tracking your individual changes is important because sometimes you’ll just be wrong when you change some code and you’ll have to check out an earlier version. These features are very important on projects and teams of any type of size.

Subversion and GitHub can be done on a local computer (not necessarily a server) and from what I know they are not exceptionally hard to install and setup. We chose a commercial host for a variety of reasons. First, I don’t want to purchase and maintain a server with all of the security nightmares that can come with it – the commercial host keeps up with security issues and we all connect via SSL so we know our code is as safe as our passwords allow.

While we do backups of our important files the commercial host is an offsite backup for us.  They do offsite backups of their servers. I know that if my office were to burn down, get hit by a tornado or flood, I would be down as long as it would for me to get a new computer from the nearest Apple retailer and hook up to our Subversion server. That’s a huge peace of mind for me.

We use a Subversion client that is cross-platform simply to make it easier for training purposes. We use SmartSVN which has versions on Mac OS X, Windows, and Linux. While we spend 99% of our time developing our Real Studio applications on the Mac we occasionally need to compile or debug natively in Windows or Linux. The standard UI across platforms with SmartSVN makes this easy and we do not have to copy files across development environments.

We also use a bug tracking system. Unfortunately our version control and bug tracking aren’t tied together but there are plenty of commercial hosts that have both. We tend to commit based on bug reports or, at a minimum, clusters of bug reports. Have a single bug in a class? That’s one commit with the bug ID noted in the commit report. Have a couple in a set of related classes? That’s one commit with all the bug ID’s noted in the commit. At a glance I can tell what bugs were fixed with each commit.

So regardless of the reasons that appeal to you the most, you should be using some form of source and version control system. Protecting your source code assets should be a part of your practice. If you aren’t protecting your most valuable assets your playing with fire. A disaster on your development computer could put you out of business. Protect your source code and yourself.

What about you?  What do you do to protect your source code?

12 thoughts on “Protect Your Most Valuable Asset

  1. I used subversion for years, but switched to Mercurial about a year ago (in particular, I use TortoiseHg on Windows, and there are some GUI clients for the Mac, SourceTree gets high marks from threads I have read). Once I got past the difference in the two concepts I became a believer in Mercurial. Subversion checks out a revision of the source code from a central repository, while the Mercurial is distributed source control. Each one has advantages and disadvantages. And the Central Repository in Subversion is easier to get your head around initially. But once I figured out what everyone is raving about distributed source control, I was sold. Mercurial just merges code better, although one caveat with RB, when you add controls, it really makes some serious changes to the RBVCP format (moves sections of the source file around) and even mercurial can occasionally have fits trying to merge it. But straight code changes are usually not a problem, handles it very well.

    On a related note, as a single Developer Micro ISV, I recently switched to Crash Plan for my backups. Probably plenty other good ones out there as well, but I like being able to run my cloud and local backups from the same app. Costs peanuts a month, unlimited backup and retains multiple revisions. Seems to work versy well so far.

  2. I use extensively atlassian’s JIRA and FishEye for Bugtracking and Stash for GIT repo server, from the same company, while I keep Bitbucket for other projects. For $30 you get a 10 developers license, unlimited repositories, and best of Agile development enviroment (Scrum). For hardware I recommend better than a Time Capsule a micro HP server with ESXI, for Raid 5/10 and inexpensive 2TB HDs. OpenMediaVault is installed in the HP Microserver for some testing (Linux, Windows). I highly recommend atlassian’s products for individual or small teams.

  3. I use a TortoiseSVN repository situated in an encrypted folder thats in my Dropbox account. The Boxcryptor program mounts this folder as a virtual drive on my machines on computer start up.
    So it’s pretty seamless to check-in and check-out.
    Encrypting the stuff in my dropbox is possibly being a bit paranoid.

  4. @jjb I tried Dropbox, but didn’t like having to put things in one set place. I prefer the approach of putting my directories whereever I want and telling the backup software to back it up in place. I realize that the repository is not really going to move around, but until you check stuff back into the SVN repository, it is not getting backed up (unless of course, your working directory is also in Dropbox, but that brings up the other issue of having to put things in one location).

  5. @ Christian, Yes that’s what I thought, I don’t like the fact that they can do that.

    @Merv Well on the virtual drive that Boxcryptor creates I can put it anywhere I like 🙂
    I try to commit very frequently. I would certainly not go beyond a day at the very most without a commit and often several times a day.
    The software SugarSync is like dropbox but allows you to select which folders you wish to sync/backup. That sounds more like what you want.

  6. Actually guys your MOST valuable asset is yourself.
    Take care of yourselves as fastidiously as you do your code.
    Get away from the keyboard when necessary (having had tendonitis & bursitis for the last 20+ years it’s no fun when you cannot feel your fingers at the end of the day & your arm hurts so bad amputating it would feel good)

    And once you do that – back up your code somewhere (offsite, SVN, git, whatever)
    Backup it up often.
    I have 2 time machine set ups (one at my home & one at my office) & I use those both.
    At least one is always “offsite” – the chances both my office & my home go up at the same time are low. And anything I work on for clients is on their servers of backed up separately to a remote service.

  7. @jjb Yes, I’ve got SugarSync as well, but really only use the Magic Briefcase in it for quickly transferring files between computers. Unless you have a real need to keep multiple computers in sync, it is better to use backup software instead of syncing software. While investigating all the backup solutions, I read some posts of developers that had a hard drive malfunction on one of the computers, and somehow, SugarSync interpreted the problem as the files being deleted by the user, so it deleted the project on all the computers that were synced. SugarSync claims they maintain the past 5 versions on their servers, but they couldn’t get them for the developer for some reason. Porject was gone, because the developer used the other synced computers as his “backup”. It is not the same thing! Again, some people may need to keep projects in sync on multiple computers, but I have one master machine and it gets backed up. If I need to work on another computer, I just restore to that computer. Every developers needs/preferences are different.

  8. @npalardy
    Having had 2 bouts of back pain in recent years I couldn’t agree with you more. I find that walking helps a lot, I try to do 3 to 6 miles daily. It’s great for clearing the head too.

    @Merv That is a horror story! Personally I am probably counting on Boxcryptor/Dropbox a bit too muchas I’ve more or less given up using external hard drives.
    Actually I had a look today at Crash Plan and it’s interesting.

  9. I looked at several backup solutions and settled on CrashPlan. It got pretty good marks in the reviews. I used Jungle Disk / Amazon S3 for years, but was never crazy about their interface. CrashPlan had a 20% off special, signed up for 2 years for $72, that’s $3/month, but I think most services are in the $3 to $5/month range anyway. I also like running both my local backup and my cloud backup from the same app. The only time I need to touch it is when I add or remove stuff from the backup list. About the only thing I don’t like about CrashPlan, is the backup and restore lists are not alphabetized, it gets listed in the order they are phycially on your drive, but that is a minor quibble.

    SugarSync is sweet like the interface better than any other, but I am trusting my backups to a Sync service. If they ever add true backups, I’ll probably revisit it.

Comments are closed.