With DVCS s people can maintain their own local branches without making any changes in the central repository, and push their changes to the master repository when they think it s cooked up. Our project is stored in an SVN repository but personally I use git-svn to manage my local changes and find it quite useful, because we are not allowed to submit all the changes immediately(they have to be approved by the integrator first).

It all depends on how you want to work on projects. Distributed environments are great if everybody wants to build on its own branch. I prefer a central repository for my work (in a small team) as it makes the developers think about releasing one version of our product.

In my experience I see a lot of DVCS users who think of their own changes as the ones they don t have to review and these users review the changes of all other developers before merging them in their own tree. I like to see my changes as the change to the core product, so I review these changes before I commit them. As a result we try to keep the product pretty stable during the entire development cycle. Refactoring works OK, as we all update often.

Several DVCS users I know prefer to work on their feature on an independent tree and leave the integration with the central product to the final phase of their development. This works fine if the feature is independent, but I wouldn t like to be the one who has to integrate all the features developed this way with a deadline in sight.

If you integrate often, DVCS s don t differ much from central VCS s, and most DVCS s support a central repository, while more and more central VCS s support several features that where unique to DVCS s before, like offline commit and shelving.

(FYI: Offline commits are planned for Subversion 1.8)

Personally, I find it s a huge benefit. Even with a central repo, a DVCS changes the flow from "edit code, update from central, commit" to "edit code, commit, push to central". Among other things, that means that conflict resolution is far less stressful. It can also encourage development in smaller chunks, since you don t have to push after every commit. If your team is OK with it, that means your individual commits might leave the app in a strange state, as long as it s working when you finally push to the central repo. If they re not OK with that, as long as you re using git (or patch queues for hg, IIRC), you can still do dev in the same style, but then condense all your smaller commits into one larger commit that is complete before you push it to the central repo.

The big benefit of using a DVCS for me is that I can commit to my local repository without having to share these changes with everyone else. So when working on a big change I do small incremental commits, meaning I can revert just the last 30 minutes work, or do a diff against a version that was working yesterday, but then only push to the central repository once all my work is complete.

I think this benefit alone is worth moving to a DVCS for.

However, using a DVCS does require a little more thought and understanding and using a "standard" version control system like SVN or CVS so you will need to consider the training overhead if moving to a DVCS or your central repository will end up full of a lot different branches people didn t realise they were creating.

You ll get the inevitable war of Git vs. Mercurial starting here soon... :-) I personally use Mercurial, but what I ve got to say should be suitable for all DVCS.

In my opinion, yes, they are suitable for corporate use. I use them at my own company, albeit with a small number of developers using it, but if you re worried about scalability, look at the large Open source projects using git and mercurial, e.g. Mozilla, Python.

The central hub approach works well - it s a familiar working model to users of subversion and you ve always got a "definitive" version. Lock down access to this and apply any hooks to enforce commit policies and after that, developers have a large amount of freedom to work how they like with their local copies.

Another big plus is that I ve found merging much less painful with mercurial than with subversion.

What s trickier with a DVCS is managing binary files - you can t require a lock on a binary file like you can with subversion (amongst others). Manage this with communication ideally.

Finally, cloning a repo is great for keeping checkouts in sync if you re working from several PCs.

Hope this helps. K

I think the main benefit of a DVCS comes when you want to push your changes directly to other people (or machines, e.g. taking the repository home with you), without going through a central hub. If you have the need to do this, a DVCS is definitely the way to go. If, as you say,

all you are doing with a DVCS is creating a central hub that everyone pushes their changes to

then you’re not really taking advantage of the main purpose of a DVCS and I would say SVN is sufficient.

P.S. One might also make the argument that a DVCS encourages users to commit more often since they can do so in their personal repository and only publish their changes when they’re ready — but this can be easily accomplished in SVN using branches, with the only “downside” being that “personal” commits increment the version number of the whole repository.

Even with a hub workflow, a DVCS gets you the ability to make small commits locally, merge them only when you want to, and push them when they are ready.

With a non-DVCS, you are forced to either:

1. do your work without committing, until it s polished and you push a huge commit.
2. make small commits as you go, which everyone has to merge often, though merging intermediate commits brings them nothing of value.

And if you explore a dead end, without DVCS: with the first method, you can t rewind, you don t have a commit to go back to; with the second, both your commits and their reverts had to be merged pointlessly by everyone else.

Personally i think the biggest advantage of DVCS is that you commit (locally) before merging, so if halfway through the merge it turns out to be more complex than you originally thought, it is trivial to get back to a clean state without losing your work. compare to CVCS where you usually have to merge succesfully before you can commit.

additional advantages include:

• working from home/at clients site becomes easier as you don t require network connection just to check something in, and if you wait till back at base to push changes the history is preserved rather than lumping everything into one change.
• Most DVCS operations are actually a lot faster as they don t need to pull data over the network
• Some things (e.g. user settings scripts) are better shared directly between developers who want to share them rather than via a central location

In my experience there are several ways to use a DVCS inside a corporate environment:

• Multi-site support: you ve separated teams and you use your DVCS to set up different "servers" at each location so they re not limited by the underlying network problems (and believe me, there will be). It used to be done with "big things" like Clearcase Multi-site or Wandisco (for SVN/CVS) but now it s pretty doable with DVCS systems.

• Support "roaming users": you re a corp. developer but you want to work at home for a certain time (or ever): instead of relying on the VPN you can have a DVCS at your laptop and then you re free to commit, review, diff, branch and merge without being slow down by the central server. You synch back when you re online or back at the office.

• True "distributed development": which is the extreme case: each developer having his own DVCS (like you d do on the OSS world). It will really depend on team s skills and motivation: if the team really wants to move into it, they ll benefit, otherwise it will be SYSADM s nightmare having to manage not a single repo but hundreds... with their corresponding issues.

the overhead is not so big, in fact, in our environment, the added hg push is less of an overhead than commiting to the central svn repo was. but the biggest plus is all the bells and whistles that come with mercurial, that are great for an individual developer regardless of the team size or workflow. first and foremost, the fact that every wc is a repo is great, since you can experiment much more freely without polluting the master repo. then, there is functionality that builds on the wc == repo equality: bisect to quickly find the revision where a bug sneaked in, grep to, well, grep the history, as well as functionality simply missing from subversion, like colored diffs in the terminal.

Bazaar VCS can work as distributed VCS and as centralized VCS so you have the freedom to select the workflow you need. In the same time local private branches (where people can experiment while working on new features and in the same time commit their progress regularly) is huge benefit.

Also DVCS makes natural development workflow when mandatory code review required before new changes will be landed to trunk. This workflow (regarding SVN) described brilliantly in the UQDS article. And despite the fact that article described SVN-based workflow you ll find it more natural when you re using any DVCS instead of SVN, because in DVCS branching and merging is basic first-class operation.