Which version control system is best for you?




Client-server vs distributed

There are two main types of version control system available: client-server and distributed. There are also local-only systems, such as RCS, which operate on a single machine at a time, but those are very little-used now - it's both easier and more flexible to use a more modern system, even if you're only operating it locally.

Client-server systems work on a centralised model, where there's a copy of the current code on a central server, which users check out in order to work on locally. When a user has finished making their changes, they update against the central version (in case other people have made changes in the meantime), deal with any conflicts that might have arisen, and then check their code into the server, whereupon other people can check it out again.

Distributed systems are structured on a peer-to-peer basis: instead of one centralised repository, everyone has their own repository, and you synchronise by exchanging change-sets in the form of patches, or by merging branches. In practice, however, most projects of any significant size will have a single copy nominated as the main development branch, but this is a social difference rather than a technical one.

Both systems have advantages and disadvantages. Some of the advantages of distributed systems are:

  • They provide a full backup of the codebase and change history with each branch, and there are many branches.
  • It's easier to work without a network connection, because you can commit changes to your own local repository.
  • Collaborating directly with other developers is easier, because you don't have to go through a central system.
  • It's easier to create and destroy branches, and therefore easier to conduct experiments when developing!
  • Some people see it as more empowering, encouraging new people to get involved in a project.
  • It's possible to have multiple 'central' branches for different uses (stable, development or release branches, for example).
  • Committing, viewing history, and other similar operations are fast, because there's no need to access a central server.
  • Merging is in general much easier.

Centralised systems also have advantages:

  • It's possible for a single person or entity to keep control of the whole history and project access (this can obviously be seen as an advantage in some circumstances and a disadvantage in others!).
  • A 'master version' of the code is kept centrally, rather than having multiple competing versions.
  • The central server can be explicitly designed and set up to be fault-tolerant, rather than relying on lots of people's personal machines.

In short, both types of versioning methods have their advantages, although distributed systems are becoming increasingly popular these days.

Other contenders

Perforce Popular setup using a centralised client-server model. Perforce is under active development, but the downside is that it's proprietary: it's free for up to two users or for OSS projects, but $900 per seat otherwise.
CVS Released in 1986, this is just about the oldest full version control system around. It's centralised, with some very well-publicised drawbacks (such as the high cost of branching/merging). It's still in use and still maintained, but new features are no longer being added, and for a new project you'd be better off with another option.
Mercurial Another distributed system in active development. It has a neat patch queue system, and the command line abbreviation is hg, which should remind you of your chemistry lessons.


Bazaar (bzr on the command line) is a distributed system that calls itself 'version control for human beings'. It aims to support a variety of types of workflow, giving you significant control over the way you choose to work and to use version control. It's also possible to use Bazaar with other version control systems, or with the repositories from other systems (such as CVS or Subversion).





Getting a diff from Bazaar and checking the repository status.

Getting a diff from Bazaar and checking the repository status.

Work offline














Setting up and importing into a repository. This directory already has a Git repository, so all that information is also being imported


Conflict resolution




Tagged commits


$ svn propset test "test property value" myfile.txt
$ svn proplist myfile.txt 
Properties on 'myfile.txt'
$ svn propget test myfile.txt test property value








It's compatible...

Like Bazaar, Git works with Subversion: you can use a Subversion repository directly with Git, using the git-svn commands. This can be massively useful if you just want to try it out, or if you're working with a project that uses SVN and doesn't intend to change.

Although largely similar, the commands are slightly different in a couple of cases from the ones used by SVN and Bazaar. There are a couple of really neat changes: for example, git diff automatically uses less as a pager rather than you having to remember to run it through a pipe.

It also has an interesting security feature: the history is stored in such a way that the name of a revision depends on the history to that point. Once the revision is published, it can't be changed without the change being visible.

In practice, this means that revisions are identified with SHA1 IDs: 160-bit hex numbers. The downside to this is that it's harder to use a revision number to identify a particular revision to work with, since they're long and complicated. However, Git will autocomplete for you, and there's always cut and paste.

Tags in Git are extremely powerful. You can attach an arbitrary description to the tag: in some cases, projects store a whole release announcement as the description. The name of the tagger is stored, and the tag can be PGP signed, thus, again, confirming not only the person's identity, but also the validity of the revision, history and tree through the revision ID system.

Unlike Subversion, when you merge branches, the full history of both branches is preserved, and branches can be repeatedly merged. Git really does put a big priority on flexibility and the ability to merge repeatedly and from multiple directions. As well as dealing well with patches (changesets), it also has strong support for applying patches that come in by email. You can directly feed in a mailbox with patch emails and it will grab the patches and apply them. There's also the StGIT tool for maintaining sets of patches.

Setting up a directory as a Git repository is painless. The # lines in the middle are the status output.


Get your hooks in

As with both Bazaar and Subversion, Git has support for hooks: scripts that are set to run before or after particular events (eg checking for trailing whitespace before running a commit and exiting if any is found; or sending an email after a commit).

One slight problem Git does have is an inefficient use of space: each new object is stored as a separate file. To get around this, files are intermittently 'packed' together to save space.


All three of the version control systems compared here are really good pieces of software: what you use depends on what your requirements are.

For an ultra-distributed setup, with lots of developers working largely independently, Git has major advantages. If you're working on your own, using a distributed system can also make sense, because it's so easy to create a new repository, even from an existing directory. And the easier you make it for yourself to use version control, the more likely you are to do it. However, make sure your backups are happening regularly!

For a more centralised project, Subversion has advantages - and there's plenty of support available for it. Bazaar is good as a bridge of sorts between centralised and distributed systems: despite its being distributed, it's easy to use in a more centralised way if that suits your project better.

Happily, the cost of experimenting with all of these various version control methods is low, especially for the distributed systems - so it's easy just to pick one and start using version control straight away, and then switch systems if you want to try another one at a later stage.

First published in Linux Format

First published in Linux Format magazine

You should follow us on Identi.ca or Twitter

Your comments

Yes, I am the first commenter!!!!

I remember reading this article in LXF, good one guys!!!



Not an issue if you're using a distributed DVCS. You keep control of the code in one server, and people do whatever they want -- but you call the server version "official", and that's it.


And you can do this with distributed VCSs. Lots of projects do that, actually.


There's no reason why you can't set up a reliable server using a decentralized VCS. Actually, you can easily set up dizens of reliable servers ---- distributed VCSs make it very easy to set up a replicated setup.

*Wonders whether Linux

*Wonders whether Linux format will still have articles like this when Linux is mainstream*

Seriously, why should I care about this stuff unless I am a coder? I am an end user and so long as the coders are happy I am happy.

Not just for coders

Okay so I use systems like these for coding with and they are invaluable for that, but they are also really useful for non-coding work as well.

If you've got a document which needs to be accessed and edited by several people its great, what if you want to modify a photo, instead of making loads of copies every time you want to make a change you could version control it. How about keep hold of different revisions of a spreadsheet? Version control it.

I loved this article when it was in the magazine, how about doing a bit more in-depth review for each one guys!

Great for non-coders

As pointed out above - version control is something that is useful for personal uses along with others. Are you an graphics artist? translator? you might want to learn the basics of a vcs so you can help contribute to a project. If not, you'll prolly be taught it anyway - it's designed to be simple (well, all save for git. It's for "real" people).

Vadim P: Git is for a

Vadim P: Git is for a specific group of people since it was designed for a specific goal. Plus it's still fairly straightforward.

I'm wondering if there are any GUIs available for Git version management? I like using GUIs rather than the commandline for version control...

Version control for large binary directories

I have to do many simulations per day, and my 'simulations' directory usually has 10Gb. Of that amount of information, I modify some hundreds of MiBs.
I'm looking for a tool to help me with this. I've tried unison, but it is based on a pairwise comparison, I'm more interested in something in the spirit of GIT.
Will GIT be efficient for this scenario?
I hope you can point me to some solutions for this.
Thanks in advance.

Also interested in version control for large binaries

I want version control for my A/V production house. We have around 3TB of data, mostly audio files around 1-2GB, video files around 20-40GB, and "project" files around 1-20MB.

The project files change several times daily. The big media files do change, but not frequently, and perhaps only 2 or 3 times total.

Anyone know of a version control system that would be good in this scenario?

Merge Hell

Our company used GIT until about 2 months ago. We are a smallish team of 10 devs but are constantly prototyping new ideas.

On the surface GIT sounds great where everybody branches off and merges what they want to merge. In practice this just led to some really complicated merging. We were spending more and more time merging changes - and we were 'loosing' more and more changes with bad merges.

So we have gone back to a centralized server using PureCM. We definitely find that having a controlled flow of merging makes life simpler (even if it does appear more restrictive).

We are constantly editing the same source files as each other - so GIT might work better if each developer generally works in a separate area.

Which version control system on windows XP OS

our company have totally 10 developers and we are using windows xp operating system. So which version control system is better for us. Is CVS is fine for us or any.

"In practice this just led

"In practice this just led to some really complicated merging."

I'm wondering what your workflow and social interactions looked like. Of course, if you have 10 people randomly branching and merging from each other with no clear, common direction, then that'll become a mess. You'll end up actually having 10 different, seperate projects and get into this merging mess when deadlines get closer.

While git does not technically enforce controlled, centralized work flows, that doesn't mean you cannot do so with git - it can and should be done, but on a more social level though.

When you have more than 3 or 4 people you should introduce some hierarchie, have maintainers of subsystems, people who try to enforce some common direction, people who regularly check whether the project is still on the right track.


To me this sounds more like a lack of project management and software design, especially missing abstraction and modularization, and a lack of general git workflow experience - than being git's fault.

Of course, I do not know the details of your project and how difficult it is to enforce modularization there. But still if modularization is tricky in your project, then you can still enforce any degree of centralism suitable to your project in git. A version control system with decentral features does not forbid using hierarchies, it is not exclusive.

Comment viewing options


Post new comment


Username:   Password:
Create Account | About TuxRadar