Chris Adamson recently blogged, “what are the advantages of distributed SCM, beyond the globe-spanning mega-projects?” I’ve been hearing that question for a long time; it started whenever a new engineer joined a Sun project and had trouble getting their head around TeamWare. But it’s hard to answer that question except with, “try it for a while and you’ll see.”

The reason that’s a hard question to answer is because a distributed SCM creeps up on you and changes the way you work, in a subtle way you don’t notice until you have to work on a single-repository SCM again. The reason is that branching is very easy on a distributed SCM and so you use it all the time; it’s so easy that you rarely notice you are branching. Anytime engineers want to work on something independently, whether it be in different cities across the globe, between co-workers, or just by themselves working on two projects at once, all you do is clone the repository you want to work with from some other copy, which becomes the parent of your new copy. Make any changes you like in this copy, then commit them when you like them as usual. Just like any other SCM, right? Wrong, as the commit only happens in your copy; you need to merge your copy with its parent to share it with the parent’s other child repositories.

It sounds like more work, but it’s the opposite because it fits better with how most software engineers go about their jobs. Child repositories can work as safety nets, so you can try wild experiments and if they don’t work, just delete their repositories (and no need to broadcast your failures with the world like with a branch in a single-repository SCM). Independent bug fixes need parallel code reviews? Just keep them in separate repositories and there won’t be any risk of accidentally changing them before they are merged. A couple of team members are working on a side-project? Just copy a repository to hold your shared work, then copy individual ones so you don’t step on each other. As time goes on you’ll find you are cloning copies all over the place, and your productivity improves since your SCM system supports how you juggle your responsibilities.

Most source control management systems support branches, but the big difference with a distributed SCM system is that branches don’t have to be explicitly created since you are always working on one or more branches. Branches with single-repository systems can be a headache many team avoid whenever possible; SCM advocates may claim otherwise, but that’s been my experience working with CVS, Subversion, and Perforce. Developers are conceptually branching and merging as they write software all the time, whether it be in big teams or as individuals, so their version control system should make branching and weaving as easy as possible. It’s counterproductive for a tool to fight the natural way most of us work.

It reminds me of when I got my first pair of noise-canceling earphones. I put them on, didn’t hear anything different, and thought they were useless; but after wearing them for awhile, I took them off and was shocked at how loud my “quiet” room really was. I couldn’t hear the normal noise until I grew accustomed to quiet.

It’s that “fighting the flow” issue which makes it so hard to make the case for distributed SCM systems. When you start using a distributed SCM, it may seem to be the same experience as a single-repository SCM, and so what’s the big deal? The “it’s a big deal” moment happens when you switch back to a team using a single-repository, and then you find that not being able to easily branch and merge is a constant irritant and productivity drain.

Oh, and I forgot a reason why even Chris might make the switch: distributed SCM systems work fine off the grid, such as on airplanes. Try doing that with your java.net CVS or Subversion-based project!

Source/Kaynak : http://www.java.net/blog/2008/09/12/distributed-scm-you-dont-get-it-until-you-got-it