Version control, revision control or, in programming terms, source control systems are different names for one thing – a system that manages different versions of your digital work. In this article SCM abbreviation will be used to refer to it. In most cases they are used for source code (text files) management, but there is nothing limiting them from managing other types of files. Documents, spreadsheets, presentations, graphics are all viable candidates.

This article analyzes designer’s needs and shows how he or she can use SCM to help organize its work files. The first part shows why it’s good to use version control systems, explains what types of those systems exist and how they work. In part 2 we’ll use one to set up a few workflows that could be good for design work.

• Part 1 – why and how (this one)
  • Part 2 – setup and examples

Why

Designers asked if they use a SCM will usually supply a blank stare and ask “why?”. It is a valid question and one that deserves an answer.

Every designer has its own workflow but most of them (if they know what they are doing) save different versions of a long project. They copy and rename the main project folder or archive/compress it for future reference and for backup. After some time the folder can start to look like this:

project/
    project_current/
    project_releaseMay2010/
    project_goneB&W/
    ...
    project_wireframes/
    archive2009.zip

Every folder has some or all the files of the current version. It is hard to track what happened to a individual file over time. And what if you work on a file for some time and decided that you want to undo the last two days of editing because you are not pleased with the result? It makes it even more problematic if you don’t have a recent backup and the file from the most recent “archive” folder is from … well … May. AND that’s just ONE person working on a project. Add two more and you’ll probably have a few more mortal enemies in your life.

A simple knowledge of a SCM can save you all that trouble and that’s the main answer to the “why?” question.

There are many developer specific tools for SCM, but not so many design oriented. There are a few, like Timeline, Adobe Version Cue or Softimage Alienbrain, that solve specific problems (like PSD files and their comparison) or have enterprise capabilities. The prices will vary depending on the feature list – you can expect to pay from $50 to $100000 (yes, six digits) for some studio editions. They are good and as one guy said:

… they have to be and you’ll tell that yourselves even if they aren’t because otherwise you’ll be painfully aware that you have just lost your pension.

But is this really necessary for normal work? My opinion is that you can adapt the general SCM (free!) for your workflow to remove common problems. The tools mentioned above can be helpful, but its’ not a show stopper if you don’t have them. It is comforting to know that some of those tools are just a nice graphical interface to a general SCM (we will use here) that hides in the background.

Before we start with use cases and examples, let us see how a SCM works and in what flavors it can be found.

Basic introduction to version control systems

Two terms are very important to grasp early on – a repository and a working copy.

1. Repository is an archive of all the changes made in the past. In the earlier example, the repository would contain all the folders: project_current, project_releaseMay2010, project_goneB&W, etc.
2. Working copy is just a snapshot in time from the repository or, more common, the current files you’re working on. When you make some changes to the working copy and are satisfied with the result, you will want to commit those changes to the repository. I’ll explain it more later, so don’t worry if it’s not totally clear for now.

Here’s a picture showing the relationship between a repository and a working copy. Committing changes to a repository and updating a working copy to an earlier version of your work are two most common operations you’ll encounter.

There are two types of SCM – centralized and distributed. The differences will not matter much for a simple work by a solo designer, but if a team works on a project, those differences can be crucial.

1. In centralized systems there is one repository and multiple working copies that can be of different versions. Every team member updates his working copy from that central repository (usually a shared server). The most popular centralized SCM is Subversion.
2. In distributed systems the repository is bundled with every working copy. That way every team member can have a whole history locally. All distributed repositories are equals so usually the team leader declares that his repository is the main one, so he synchronizes the changes from others when some important work is done. Everyone can have as many repositories as he wants. The most popular distributed SCMs are Mercurial, Git and Bazaar.

As most designers are visually oriented, lets put that in pictures. We’ll have John and Amy working with both types of SCM.

We’ll finish here for now. In Part 2 we’ll look how to install and use a SCM. I’ll also show you some workflows I used for design work so you can go from there and create your own. Check out our RSS feed or follow me on Twitter to get notified when Part 2 comes out, add comment below or nudge me on Twitter if you want to see some specific questions answered.