[flurpitude]

The Mercurial support is very welcome for those of us who found it a battle getting our employers to switch from SVN to Mercurial and don't want to go through that again. Unlike the transition from SVN to a DVCS, a transition from Mercurial to Git would not really be of any great advantage. And our code is not open source so it doesn't make much sense switching just because in the wider world Mercurial is out of fashion.

[crisnoble]

>...those of us who found it a battle getting our employers to switch from SVN to Mercurial...

Any tips for someone still fighting resistance to move to a DCVS?

[samspot]

I don't know if this helps you, but try telling them that they can leave the 'distributed' part for later. At my company we still have a 'central' repository. We'd really need to know more about your companies objections to DVCS to give advice.

I personally just started using mercurial local-only alongside svn, and as new projects started I would try to make mercurial the default repo for that project. This worked well for me, but my company is pretty laid-back about these kinds of things.

[VLM]

The best application of "embrace, extend, extinguish" I ever saw:

1) Replicate SVN workflow in GIT. SVNs features/limitations are a tiny subset of GIT so this works well. Not too proud to admit the first day had a handwritten translation cheatsheet. 2) Stop worrying about branching and merging being evil, last year rolled out git flow which mostly just formalized and standardized whats already being done, etc. 3) Shut down the old SVN infrastructure after its unused long enough.

[larrywright]

I think for an enterprise, the D part of DVCS isn't much of a selling point. What is a good selling point is all of the other stuff that makes Git/HG awesome, like easy branching and merging. There's also Github Enterprise, which if you can pay for it is really fantastic.

[kscaldef]

The D can be a selling point. Some things D enables:

Working offline is completely transparent. If your employees are on an airplane, or if the wifi at the conference they are at is overloaded, or if the central repository goes down for some reason, people can continue to work normally.

Code review based on asking for permission, not forgiveness. While the UI is a bit horrid, gerrit has been a huge win for us when it comes to code reviewing changes before they are out "in the public". When code review happens after something gets committed to the main repo, it's far to easy for issues to get forgotten about and never addressed. (Of course, Github pull requests have a better UI than Gerrit, but you might have reasons not to want to entrust your code to Github. And, also of course, this isn't strictly something that can only be done in a distributed VCS, but it seems to be a lot more natural in that context.)