Getting started with distributed version Control systems: Learn and compare the way bazaar, mercurial, and git are used

Description: Are you interested in distributed version control, but are confused by a lot of jargon? This article describes three major systems (Git, Mercurial, and Bazaar), discusses some of the benefits of using distributed workflows, and compares common operations for distributed versioning.

Brief introduction

Over the past few years, there has been a lot of debate about the benefits that distributed versioning can provide to the development process. Recently, distributed tools have matured. While some of the benefits of distributed tools may not initially be obvious, the flexibility they provide in the long run is significant. After reading this article, you should be able to start using a distributed version control system, with a basic understanding of the benefits distributed models can provide.

The controversy surrounding distributed versioning focuses on central servers that are no longer needed. This is a very unique feature that is important for some developer groups, but its real value is that it allows the developer group to implement almost any workflow they choose. It can accomplish a lot of things, such as a traditional centralized model, or two of developers working together in a café through a wireless connection, and so on.

Allowing developers to work in a variety of new ways is a truly exciting feature of distributed version control. In fact, the end of this article describes how to implement such a "café" workflow. This is useful for writers, school teachers, and linux® kernel developers.

What is distributed version control?

Distributed version Control (DVCS) is a way of managing file versions that do not require a central server, but it can also use a hub server. Changes can be merged into the system of any other user in DVCS, so a very flexible workflow can be implemented.

The two main advantages of DVCS are that it is more flexible than centralized versioning because it supports a variety of workflows in addition to traditional (centralized) workflows; it is much faster than a centralized server because most operations are done locally on the client and do not require network operations.

Major differences between DVCS and centralized version control systems

There are three key differences between DVCS and centralized version control systems. The first difference is that DVCS is supported offline through local submissions, which is determined by the way DVCS operates. This is completely different from centralized versioning, which requires that all operations be performed through a connection to a hub server. This flexibility allows developers to work on airplanes as easily as they do in an office, and can submit them again and again.

The second difference is that DVCS is more flexible than a centralized system because the DVCS supports many different types of workflows, from traditional centralized workflows to pure special workflows, to a combination of special workflows and centralized workflows. This flexibility allows development through e-mail, peer-to-peer networking, and any way the development team likes.

The third difference is that DVCS is much faster than a centralized version control system because most operations are performed on the client, very quickly. In addition, the speed is faster when a push operation is required (to communicate with another node) because the full metadata is available on the two client machines. The speed difference is significant, and DVCS is about 3-10 times faster than Subversion, depending on whether a local or networked repository is used.

Distributed version Control workflows

Because DVCS is flexible enough to implement a wide variety of workflows, this article only discusses two workflows due to its limited space. Start by discussing one of the most commonly used workflows Partner workflows. According to the Partner workflow, a developer starts a project and then branches it. Then merge the changes back and forth between the branches that the different developers work on.

The second common type of workflow is to use a centralized server through local submission. In this workflow, developers work in much the same way as they do with centralized subversion repositories, but they commit locally and then push the final changes to a centralized server. This workflow has many variants, including the use of Partner workflows. Importantly, there are many ways to work, and by using DVCS, you have the flexibility to choose the work style that works best for you.