Distributed Version Control "killer applications"

Question

Considering switching to Mercurial? We are too. I'm currently studying the benefits of DVCS which turn out to be vast, lust and must.

I would love to hear from the community typical usage patterns.

Let's create a "Top (te)N" productivity feature list for DVCS (based on Mercurial, or alike).

Please describe work flows that prove to be productive for you / your team, procedures that DVCS helped you achieve/improve as well as blunt "good stuff" that DVCS gives you (don't assume stuff are clear to the novice user).

I think that such a list could help folks approaching the team with a DVCS suggestion.

This question is community wiki, obviously.

Answer 1

The "killer app" seems to be distributed teams: rather than being tied to a central server (over a slow or unreliable connection), each team can have its own repository and push changes as needed.

Answer 2

The one true actual killer feature is...

merging

DVCS (Git, Mercurial or other) are made for merging (precisely because, being distributed, merging is the key feature allowing those tools to quickly integrate code coming from various remote repositories).
SVN isn't up to the task (even today).
See:

• What makes merging in DVCS easy
• Why is branching and merging easier in Mercurial than in Subversion?
• How does Git solve the merging problem?
• What makes some version control systems better at merging?

Answer 3

Separation of committing from publishing

This is important for larger features, because it means that one can work on a series of commits to implement a feature (each commit being small and self contained, for easy finding bugs by bisecting history) to one own satisfaction, and only when they are ready to publish them.

A variant of this approach is to have separate public repository with rebasable branch with work in progress, and push (or send a pull request) only when branch is ready for inspection.

Answer 4

For OSS projects:

low entry barrier to contribute

First, most DVCS has excellent tools to work with patches (usually sent by email), both to create them and to apply them. The contributor can create a patch using any tools (although it would be best to create patch with DVCS used by project, as some DVCS put extra information in patches), and send it to mailing list of a project, or directly to project maintainer, or attach it to the bug report / feature request in an issue tracker.

Second, you don't need commit bit to be able to contribute. Just clone project repository, and you can use full power of DVCS. You can then send patches, or a pull request, or push to 'mob' branch; there are many possibilities.

It is an advantage also for project maintainer(s): he/she doesn't have to worry who can he/she trust to give "commit bit", i.e. access to repository, as it is the case in CVCS. Karl Fogel wrote in Producing Open Source Software. How to Run a Successful Free Software Project. that he found it better for the project that restrictions such as access control better be social rather than technological; DVCS takes it further thanks to not requiring to decide whether to provide permission to commit.

Answer 5

It seems that for us the "killer app" will turn to be the possibility to push code through stages.

We will have DEV repo, which all the devs are pushing into it. QA repo will accept push from the DEV repo and will build it's version of the code for testing. Once testing is complete they will push the code to Production repo (QA repo is the only one that can push changes to the production repo) from which a "production" release will be build.

This is outlined briefly in Joel's hginit (near the bottom of the page).

I will update this post once we actually implemented the described above setup.