What are the advantages of a distributed version control for a team that is effectively never distributed?

Question

When working remotely, our team only has access to our source code by remote desktop into our office PCs so we never really work in offline mode. Does a distributed version control system like Mercurial or Git still give us advantages over our current centralized Subversion set up? If so, what are they? Are there any drawbacks or pitfalls? I've read in numerous places that shifting to distributed version control requires a change in thinking. Can someone explain what needs to change in this regard?

Answer 1

As explained in the differences between DVCS and CVCS (Centralized VCS), the main advantages are:

• local commits (you can commit more often in private branches, then clean up the history you want to push to other repos)
• publication process (you pull from multiple repos, or quickly established intermediate repos to push to, where you can do intermediate tasks like continuous integration tests)

That last point required the most "change in thinking" and is a bit scary ("I can pull from any repo?!")
But once you realize the benefits, you can really have more productive development cycles because you are able to monitor (by fetching commits from your peers) the development of some of your colleagues. If they are developing a function that you need, you can start integrating it sooner.
(The thing to remember with a DVCS is that is doesn't prevent the setup of a "central" repo, for other developers to pull from)

As for continuous integration, instead of pushing directly from your repo to a central server in charge of CI, you can push to a local repo on your desktop, which will run all the tests, before pushing automatically (if "green") the code to a "central" repo.
It is so effective that you can now push to the official central repo a code that "never breaks the build", rendering your CI server pretty much useless ;)