CSC/ECE 517 Fall 2009/wiki1a 3 ee
Distributed Version Control Systems
Overview of Distributed Version Control
Distributed version control is a type of revision control system where each user has their own content repository, rather than off in a central location. This allows for greater flexibility for individual developers within a project, as they can "do what they want" to their own version of the repository, without interference from other developers. As developers wish to incorporate external changes, they can "pull" a set of changes into their own repository.
Previously, centralized systems have been the only widely used version control systems. But recently, distributed version control systems have become more and more popular for a variety of reasons.
Definitions
- Version Control - A system for managing changes and history for software source code
- Branching - In a version control system, branching is the idea of making a copy of all or part of the code base and making changes separate from the main line. This allows for developers to develop new features or experiment without "breaking the build" on the main code base
- Merging - After branching in a version control system, developers might want to reincorporate changes from a branch back into the main code base. This process of re-incorporating new changes is called merging
- Repository - The location where files under version control are stored. Repositories can take many forms, depending on the particular version control system.
Infrastructure
One reason distributed version control systems are gaining popularity is that the lack of a central "main" server empowers the individual developer.
Repositories
Instead of a central project repository, each developer has their own local repository. This local repository is fully independent and behaves just as one would expect any repository to. One can commit changes, view change logs and roll back versions. But since it is fully self-contained on the developers machine, this can be done with no network connection.[1]
Sharing Changes
When a developer commits a change to their repository, that change set is assigned a guid. If another developer on the project wants to incorporate another users changes, they can pull changes associated with a specific guid from another repository. Because each developer controls their own repository, changes can be incorporated continuously as they are needed, instead of submitting changes and waiting on a "merge-master" to integrate new features.
Branching and Merging
Another reason many projects are moving towards distributed systems is that giving each developer their own repository makes branching and merging natural.
Branching
Because every developer has their own separate repository, each of these can be viewed as a branch[2]. Branching becomes natural because just by making the local repository to start work in, the developer has created a branch. This means creating a branch is incredibly simple. In fact, its possible that on one developers machine, they might have any number of branches for working on different features or phases, each with its own repository.
Merging
Similar to branching, because each developer has their own repository, merging becomes a natural and normal part of collaboration. In order to incorporate another developers changes, you simply pull their modifications (each identified with a guid) into your local repository[3]. Your repository now has a record that the new guids have been incorporated into the local content and the repository carries that information going forward. This makes it very easy if you do multiple merges where some content could be duplicated in external repositories. If your repository already has a change associated with a particular guid, there is no need to incorporate that change.