This is another in our discussion on DVCS and git (see our git category in the right column for more). Software developers are always looking for ways to make their efforts easier. Making version control more streamlined and accessible is one area where transformative improvements are happening with git. We have been covering git and related technologies (for example, see DVCS git is trending fast in software development futures, and Atlassian Stash Powers Enterprise Application Developers with DVCS Git). We will continue a Wednesday post on aspects of git and git resources into May.
In this post I want to go over the basic differences between version control (CVCS) and the newer distributed version control (DVCS) and then discuss the pros and cons of DVCS. Traditional version control (CVCS) helps you backup, track and synchronize files. Distributed version control (DVCS) makes it easy to share changes as every change has a guid or unique id. With DVCS git, you can get the best of both worlds: simple merging and centralized releases.
First let’s look at CVCS as shown in the chart below. The central repository serves as the hub and developers act as separate spokes. All work goes through the central repository. This makes version control easy and sharing difficult.
With DVCS git there is more interaction directly between developers as shown below. Atlassian’s Stash is their offering in the DVCS git space. For more information see this Atlassian Stash overview.
This brings in a number of advantages.
Everyone has their own local sandbox.
- You can make changes and roll back, all on your local machine.
- No more giant checkins; your incremental history is in your repo.
DVCS git works offline.
- You only need to be online to share changes.
- Otherwise, you can happily stay on your local machine, checking in and undoing, no matter if the “server” is down or you’re on an airplane.
DVCS git is fast.
- Diffs, commits and reverts are all done locally.
- There’s no sketchy network or server to ask for old revisions from a year ago
DVCS handles changes very well.
- Distributed version control systems were built around sharing changes.
- Every change has a guid that makes it easy to track.
Branching and merging is easy.
- Because every developer “has their own branch”, every shared change is like reverse integration.
- The guids make it easy to automatically combine changes and avoid duplicates.
With DVCS, there is less management.
- DVCS systems are easy to get running since there is no “always-running” server software to install.
DVCS systems may not require you to “add” new users since you can just pick what URLs to pull from. There are also some disadvantages of the current versions of DVCS that you need to be aware of.
You still need a backup.
- Some claim your “backup” is the other machines that have your changes, but what if they didn’t accept them all? ** What if they’re offline and you have new changes?
You still want a machine to push changes to “just in case”.
- In Subversion, you usually dedicate a machine to store the main repo; do the same for a DVCS.
There’s not really a “latest version”.
- If there’s no central location, you don’t immediately know whether to see others for the latest version.
- A central location helps clarify what the latest “stable” release is.
There aren’t really revision numbers.
- Every repo has its own revision numbers depending on the changes.
- Instead, people refer to change numbers that are not intuitive. But, you can tag releases with meaningful names.
If you have any questions on DVCS and how best to work with git and Stash contact us at: firstname.lastname@example.org. At AppFusions we have also developed a Source Code Importer for Stash, Atlassian’s git offering. This importer significantly decreases the challenge of migrating SVN to git for use with Stash and is currently available at the Atlassian Marketplace.