Pros and cons of distributed revision control systems?

The question sebasgo is pointing to really has a lot of good answers, but let me tell you my personal experience anyway. I work with a handful of other people scattered all over the U.S. Doing what is essentially private consulting work. Clients vary in size, but our team is small, and we work fairly fast.

The code is commercial but owned by the clients when we are done. We use Mercurial, but the specific tool is less important than the general workflow of using distributed version control as opposed to centralized. In my experience there a two big advantages to productivity that I no longer want to work without: First and foremost: branching and merging are easy.

This is a side effect of being distributed, not strictly a requirement, but it's critical for a DVCS and I find it critical for my work. Each of us can freely branch each and every feature we need to work on, get it working in a sandbox (without interference from our shared repository) and when we are ready merge it back in. "Keeping up" with the changes of other is as easy as occasionally merging, with the option to throw away the merge and continue on if dealing with resolving conflicts is too much effort in the moment.

We can grab specific changes and throw them together in a test branch, and keep the results if we like them or toss them if we don't. This ability to try things out, share them, and keep only the best results is a serious benefit. As I say it's not one I can comfortably work without at this point.

Working offline. It doesn't sound like a big deal, until you aren't working in your usual environment. I can go on vacation, or travel, or have an outage, or just want to take my laptop outside on a nice day, and keep working.

The psychological benefit of being able to get up and go without needing to stop working, or lose my ability to checkpoint my work is very real. Beyond those effects, which apply to all my projects, work-related and not, one benefit specific to our particular arrangement, which relates to your question about commercial use and which was unexpected came up: the client can actually work on the code. They can take a snapshot, make local changes, and either send us back fixes or keep the tweaked code for a particular purpose.

This is of great help in keeping them involved, in not getting too far out of sync with what they want, and in allowing them to tweak things without breaking anything (we don't merge in their changes unless they are ready -- same rules we apply for ourselves. ) We don't have a lot of complaints. It takes some getting used to, though the command set of Mercurial is close enough to Subversion (which we used to use) that we've not had a lot of trouble.

Even the occasional nastiness, like accidentally checking in binaries or files that shouldn't be checked in, we can get around because we can re-create a repository without those changes, and replace our main one if we need to. This doesn't scale to a large group of people well, but works quite well for a small 3-4 person team. The one negative I can think of that's actually a problem, is a side effect of being able to branch easily: you can have enough pending work that you lose track of it.

This is a little akin to having many drafts of a written document: pass enough copies around and you don't remember which copy had the changes you want. That's not directly a flaw of the tool, and if anything it makes it easier to bring back together disparate work than tools less capable at merging would be. But it is a hazard.

The only way I know of to manage it is to be disciplined about writing useful commit logs, useful branch descriptions, and not trying to keep too many open tasks at once. In other words even a very nice workflow is still a workflow and needs attention or it gets out of hand. I have particular issues with Mercurial (I really want named branch support to be just a little bit easier) and with Git (I really want the command set to be more intuitive, even now), but they are complaints about corner issues that come with great familiarity.

They wouldn't even be possible if these tools hadn't pushed the envelope of what I thought a VCS could do far beyond what I knew before I started using them.

Read this question on stackoverflow for lots of information about GIT vs SVN and central vs distributed systems in general.

I've not tried other distributed systems so can't comment on them. But one thing that annoys me about Git is theres no way to only clone part of the repository. Last I checked, it also lacks things similar to svn:externals.

I find svn externals are often used within companies for checking out libraries from other repositories etc.

1 You can define submodules in git which allows you to only clone the submodule, however, for this your repository must have the structure already, you cannot do it when you clone. – txwikinger Jul 22 '09 at 21:12.

Yeah, checkout the stackoverflow question for this. If you want any more information about how Git compares to other revision control systems, there is a nice informative site for that: Why Is Git Better Than X?

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.