This post originated from an RSS feed registered with Java Buzz
by Mathias Bogaert.
Original Post: What is Version Control: Centralized vs. DVCS
Feed Title: Scuttlebutt
Feed URL: http://feeds.feedburner.com/AtlassianDeveloperBlog
Feed Description: tech gossip by mathias
This part of an Atlassian blog series focusing on teams switching to distributed version control systems (DVCS) like Git or Mercurial (Hg). You can find the other posts in this series under the Switch to DVCS tag. 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”. Centralized version control systems 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 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 [...]
Previous Topic
