Centralized vs. Distributed Version control systems

Centralized Version control systems

These are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

“Committing” a change simply means recording the change in the central system.

Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.

Most modern version control systems deal with “changesets”, which simply are a groups of changes (possibly to many files) that should be treated as a cohesive whole.

For example: A change to a JSP file and the corresponding .java file should always be kept together.

Programmers no longer have to keep many copies of files on their hard drives manually, because the version control tool can talk to the central copy and retrieve any version they need on the fly.

Some of the most common Centralized Version control systems are CVS, Subversion (or SVN) and Perforce.

A Typical Centralized Version Control Workflow

 1. Pull down any changes other people have made from the central server.

 2. Make your changes, and make sure they work properly.

 3. Commit your changes to the central server, so other programmers can see them.

Distributed Version control systems (DVCS)

These systems do not necessarily rely on a central server to store all the versions of a project’s files.

Instead, every developer “clones” a copy of a repository and has the full history of the project on their own hard drive. This copy (or “clone”) has all of the metadata of the original.

In practice, it’s not a problem. Most programming projects consist mostly of plain text files (and maybe a few images), and disk space is so cheap that storing many copies of a file doesn’t create a noticable dent in a hard drive’s free space.

Modern systems also compress the files to use even less space.

One common misconception about distributed version control systems is that there cannot be a central project repository.

3 most popular of these are Mercurial, Git and Bazaar.

Advantages Over Centralized Version Control

The act of cloning an entire repository gives distributed version control tools several advantages over centralized systems :

• Performing actions other than pushing(moving changes to repository) and pulling (getting new changes) changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.
• Committing new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.
• Everything but pushing and pulling can be done without an internet connection. So you can work on a plane, and you won’t be forced to commit several bugfixes as one big changeset.
• Since each programmer has a full copy of the project repository, they can share changes with one or two other people at a time if they want to get some feedback before showing the changes to everyone.

Disadvantages Compared to Centralized Version Control

There are almost no disadvantages to using a distributed version control system over a centralized one. Distributed systems do not prevent you from having a single “central” repository, they just provide more options on top of that.

There are only two major inherent disadvantages to using a distributed system : 

• If your project contains many large, binary files that cannot be easily compressed, the space needed to store all versions of these files can accumulate quickly.
• If your project has a very long history (50,000 changesets or more), downloading the entire history can take an impractical amount of time and disk space.