Selecting a Version Control Tool

In essence, a Version Control (or Revision Control) System allows a group of people working on the same project to be able to work and update without needing to email files back and forth.  With so many different Version Control Tools out on the market (or available for download on the Web), how can a designer or developer find the one that works best for his/her project needs?

Glen Stansberry took the time to review seven of the most popular Version Control systems for his blog post  7 Version Control Systems Reviewed.  In this article, he took a look at CVS, SVN, Git, Mercurial, Bazaar, LibreSource and Monotone, and identified the unique features of each.  Readers can have a better idea as to which tool would suit their needs.

A quick summary as to what Glen found looks like this:

CVS – Grandfather of the Version Control System

Not as fully featured as some

Older technology

SVN – Version control system with the widest adoption

Used by SourceForge, Apache, Python, Ruby and Google Code

Git – Fast rising star developed by Linus Torvalds, creator of Linux

Distributed Version Control System – meaning that there is no master copy of the software       being used.

Much harder to use for a beginner

Mercurial – Open source Distributed Version Control System

Designed for larger projects

Extremely fast; built with performance considered as the most important feature

Much simpler system than Git

Bazaar – referred to as “Version Control for Human Beings”

Very user-friendly

Supports many different types of workflows; can fit almost any scenario for users

Easy to modify

Embeddable, so you can add it to existing projects

LibreSource – Web portal used to manage collaborative projects

Based on Java/J2EE

More a set of visual collaborative tools to help facilitate projects and teams

Centered on tools that don’t have a big learning curve

Built-in features include Wiki pages, forums, trackers, synchronizers, files, download areas, dropboxes, forms and instant messaging

Perfect for a developer or designer who doesn’t want to deal with a lot of technical jargon

Monotone – Places a high value on integrity rather than performance

Takes a long time for a new user to download due to the extensive validation and authentication required

Fairly easy to learn if you are already familiar with CVS systems


Best Practices to Consider When Using a Version Control Tool

One of the things to remember when working as the developer of a project is to have a set of “standards” or “best practices” to follow.  This is especially important when you are collaborating as the member of a team within a project.  In his article “Best Practices for Version Control,” Anders Sandvig gives seven recommendations for version control best practices.  These include:

  1. Put everything under version control.  This means that everything you have that has anything to do with your project should be under version control.  Sandvig suggests that version control not only a place to put your code, but can be used to store email correspondence and “concept drawing on napkins” for reference.
  2. Create Sandbox Home Folders.  Sandvig states the giving each developer in a team a home folder in the repository will encourage them to use the version control system.  These could serve as experimental folders in which less experienced developers could play around with features of the tool that they would need to use in “real” projects.
  3. Use a Common Project Structure and Naming Convention. Although this is probably common sense to everyone already,  a consistent naming convention is crucial to any project.  As Sandvig mentions, this makes it easier to find files when needed.
  4. Commit Often and in Logical Chunks. How many of us have found this to be the case when working on Flash and Actionscripting?  You need to save often, or you risk losing everything that you’ve been working on.  Sandvig uses an interesting quote here that is so true: “It’s better to have a broken build in your working repository than a working build on your broken hard drive.”
  5. Write Meaningful Commit Messages.  With this recommendation, Sandvig states that it is important to always make sure that you comment when you commit anything.  Although your comment should be brief, it should describe what was changed or updated in this commit.  He goes into great detail in this step to suggest several ways in which you can standardize your comments and make them more useful later on.
  6. Do All File Operations in the Version Control System.  Whenever you need to do anything to the files  or folders, do it in the version control system.  Failure to do so can cause the changes to be lost forever.
  7. Set Up Change Notifications.  To make sure that the other members of your team are aware of what you or others have done, Sandvig suggests setting up email notifications when a commit is made.  He argues that it might encourage people into writing more useful commit messages if they know that someone else will be reading them.  He also feels that some people could learn something by reading other people’s code.

Overall, Anders Sandvig had some great things for developers to think about when working within a version control system.  If you would like to read the full article, you can find it at: http://blog.looplabel.net/2008/07/28/best-practices-for-version-control/.


Seven Basics About Version Control

Version control lets you track files over time so that, if you mess up, you can retrieve a previous file. For example, say you’re writing a paper and you save it. Okay, now you go back to the paper, do your edits and save it. Great! However, whatever you did before is gone. Let’s say that later on you go over your new draft and recall that there was a paragraph or sentence that, on second thought, you really liked but was deleted. One way of saving such files is to save it and then make a shortcut copy which you can do your edits on while retaining the original draft. The other way is by using version control.

Of course, I used a single “paper” as an example, but in large projects with many authors that are constantly being changed, a tracking system of those changes is needed to avoid chaos. A version control system will do the following for your database:

1. Save files as they are edited for quick retrieval.

2. Up-to-date file sharing

3. Allows you to go back to a previous file if the new changes are wrong.

4. Allows you to leave messages as to why you made certain changes.

5. Tags changes using the name of the person who made them.

6. Changes can be made in “isolation” to see if they work before adding them to the main file.

7. Branching. This allows you to move a copy of code into a separate area so it can be modified in isolation. Later, the work can be merged back into the main file.

These are just some simple things about version control that I recently learned. I hope they are of help.


A Feeling of Not Being In Control

Years ago, I worked at a hardware store. Somethings were new to me and others were pretty basic. Let me mention some of the basic: Hammer, screwdriver, wrench, drill, saw; things like that. Now the not-so-basic: Schedule 40 pipe, 12-2 electrical wire, oakum, carbotetrocholride, alkyd paints. Not only that, but the difference between this nail and that nail or the difference between oil and latex paint and where/where not to use them.

Recently, I have been given a task to learn some things about version control systems. Okay, this is what I know about version control systems without looking back at what I just read: Version control is about saving work that was done and being able to edit it without having to make a new file altogether. Something like that. Here is my dilemma: I didn’t know what version control was until today. Prior to today, if you would have asked me what I thought version control was, I probably would have told you that it might be akin to making sure a certain Bible version was the only one getting into the hands of people. I guess what I’m saying is that I would have never learned much of what I did in the hardware store if I would have had to learn it all in say, one semester of college.

For me, reading technical, computer-related, stuff is super boring and I don’t retain it to memory very easily. It’s like looking at one of those books on electrical engineering and trying to understand a schematic. Great if electrical engineering happens to light up your life but not so great if it enlightens you to about the same extent as a light the size of a single birthday candle. It took me weeks, months, to become familiar with the different tools and sundries that were in the hardware store that I worked in all those years ago. Then again, maybe cutting and threading black iron pipe was more interesting to me than reading about version control systems. It was. Why? Because working with black iron pipe was hands on and easy to understand. Version control systems and computer tech in general, for me anyway, isn’t.