Let’s say a person is working in a small team SCRUM environment. Several teams are working on different branches of the same code base. In our team we usually split up into pairs to work on code. Occasionally people need to take time off etc. and it would be advantageous to be able to merge person A’s code into person B’s codebase. But they often don’t want to commit at the end of the day for fear of breaking the build.
This led me to DVCS — well suited to P2P merging and doesn’t require “the big commit”. A team member suggested that TFS’s shelveset would be able to do this as well. How do the two approaches compare?
Team is currently using Subversion.
The TFS shelveset allows you to create something akin to a changeset, that isn’t stored in the main repository. This shelveset is a backup, and can be “pulled” by another developer from another machine. This “private repository”, and the ability to “pull” it is as far as the shelveset compares to DVCS. Shelvesets however are not true repositories; they are merely snapshots, they do not maintain history, and you cannot check in or manage changes as you would with the source control repository on your TFS.
A DVCS is a lot more than this; with a DVCS, you have a complete copy of the repository on your machine. You can commit locally as often as you want, storing each and every change you make; you can revert changes as much as you want, since your machine is for all intents and purposes, your source control.
And then you can push your changes to another machine (central repositor, build machine, or whatever). DVCS is a completely different and flexible paradigm, that allows but doesn’t require the use of a central repository. It frees you of having to choose between stable and frequent check-ins (you can check-in locally whenever you want, and push when you’re stable).
There’s a lot more to it. If you like, you can checkout Joel Spolskey’s excellent (and hillarious) intro to Mercurial DVCS at hginit.com.
Hope this helps,
Assaf.