We read the concept/benefits/types of Version Control Systems in our last article.
Now, I am going to shed some light on the differences between Centralized Version Control systems and Distributed Version Control Systems.
If you are fairly new to SCM and version control systems, you can direct your browser to this article where we have covered some very commonly used terms in VCS.
So, here you go…
The concept of a centralized system is that it works on a Client-Server relationship. The repository is located at one place and provides access to many clients.
Whereas, in a Distributed System, every user has a local copy of the repository in addition to the central repo on the server side.
Centralized Version Control is the simplest system with the concept of 1 central repository which servers provides latest code to the all the clients across the globe
Distributed Version Control provides flexibility and has emerged with the concept that everyone has their own repository, they don’t just check out the snapshot of the code – they fully mirror the central repository.
CVCS is easy to understand whereas DVCS has some complex process for beginners.
CVCS is dependent on the access to the server whereas DVCS provides the benefits to work offline. Everything except push and pull the code can be done without an internet connection.
CVCS is easy to administrate and has more control over users and access as it is server from one place.
DVCS is comparatively fast comparing to CVCS as you don’t have to contact the central server for every command. DVCS just takes much time on the first check-out as its mirroring the central repository on your local.
If your project has a very long history and change-sets then downloading the entire history can take an unreasonable amount of time and disk space in DVCS whereas CVCS allows you to checkout only few lines of code if you just need to work on few modules.
DVCS provides a powerful and detailed change tracking, which means fewer conflicts at the time of merge.
DVCS gives an ability that developers can share changes with one or two other members of team at a time if they want to get some feedback before showing the changes to everyone.
The revisions in DVCS are typical big guids (like fa333b7rer96cd6d3b0037d660) – it’s not incremental numbers (which is provided by CVCS) which make them harder to reference and remember.
DVCS provides an advantage wherein if the main server’s repository crashes, you still have a local repository in every developer’s local space from which you can create the main repository.
SVN and CVS are the popular tools of CVCS
GIT and Mercurial are the popular tools of DVCS
I hope now you have a good idea of differences between the different version control systems – Centralized and Distributed.
What is version control: centralized vs. DVCS
In our first entry, we explored some of the basics of any version control system – diffs and patches. Looking past diff and patches, we will now discuss version control systems. Many of you out there are familiar with centralized version control systems like Subversion (SVN), CVS, and Perforce, while others have jumped straight into the distributed version control worlds of Git and Mercurial. There are many other flavors of centralized and distributed version controls out there – each with there own advantages and disadvantages.
Centralized Version Control
There are many version control systems out there. Often they are divided into two groups: “centralized” and “distributed”.
Work smarter, better, and faster with weekly tips and how-tos.
Subscribe now
“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 C header file and the corresponding .c file should always be kept together.
Centralized version control solves the problems described in the previous post on What is Version Control?. 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 you may have heard of or used are CVS, Subversion (or SVN) and Perforce.
A Typical Centralized Version Control Workflow
When you’re working with a centralized verison control system, your workflow for adding a new feature or fixing a bug in your project will usually look something like this:
- Pull down any changes other people have made from the central server.
- Make your changes, and make sure they work properly.
- Commit your changes to the central server, so other programmers can see them.
Distributed Version Control
In the past five years or so a new breed of tools has appeared: so-called “distributed” version control systems (DVCS for short). The three most popular of these are Mercurial, Git and Bazaar.
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.
This method may sound wasteful, but 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.
The act of getting new changes from a repository is usually called “pulling,” and the act of moving your own changes to a repository is called “pushing”. In both cases, you move changesets (changes to files groups as coherent wholes), not single-file diffs.
One common misconception about distributed version control systems is that there cannot be a central project repository. This is simply not true – there is nothing stopping you from saying “this copy of the project is the authoritative one.” This means that instead of a central repository being required by the tools you use, it is now optional and purely a social issue.
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 and pulling 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
To be quite honest, 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.
The authors and contributors of modern distributed version control systems are working on solving these problems, but at the moment, no bundled, built-in features solve them.
Conclusion
Version control systems aim to solve a specific problem that programmers face: “storing and sharing multiple versions of code files.” If you’re a programmer of any kind and you don’t use any kind of version control, you should start right now. It will make your life easier.