Distributed Version Control "killer applications"

Consider开发者_运维技巧ing switching to Mercurial or Git? 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 N" productivity feature list for DVCS (based on Mercurial, Git 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.

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?

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.

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.

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.

Most functionality is available offline

With centralised VCS like Subversion, the only thing you can do when offline is edit stuff. Some systems do give limited access to other functionality (e.g. in Subversion you can diff to and revert to the latest version from the repo), but most of what makes VCS useful, that is

• reading history
• checking out old versions
• committing
• creating branches

is only possible if you are connected to the central server.

With a DVCS, all the operations above work locally, and if something needs to go into the central server, you can always push it there later, when you are online again.

While this is probably unimportant if you are always online (such as at the office), it can be critical if you often have to work offline, such as while traveling or at home with a flaky connection.

I started using git specifically because I often work on the road and usually don't have a (reliable) connection.

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.

Sharing changes with others without publishing

For me the killer app, when I was a large team, was being able to work together with other engineers, sharing changes, without needing to go through the central server. It meant we could share unfinished features in a controlled way (i.e. no "copy this file from my tree") and it all just worked.

• Alice starts work on a feature, but it needs Bob to do some stuff before release.
• Bob takes Alice's changes directly, finishes off the feature. Alice and Bob might have stuff going back and forth between them.
• Charlie, the QA guy, takes Bob and Alice's changes from one of them. Tests them. They're ok! He pushes the whole lot onto the main server. Everybody else can now get the feature - complete and tested.