Major Edit: Added more info about how the devs are setup and how a DVCS would help, so you don't have to second guess the DVCS (but you are still welcome to do it =P).
I just started a new job and I'm currently at the process of trying to introduce a DVCS (mercurial, but the actual DVCS is not really a matter of discussion at this point, it could also be git) to the company (big, multinational). So far I've gotten nothing but positive attention, even at managerial and directive level, but I want to make sure I'm not at all disruptive to the organization or anyone's jobs.
The way the developers are setup is in a team room, so there's a lot of communication going on. There is also an integrator, that communicates on a daily basis two or three times with the team leader. Also, there are more dev teams on other parts of the world, maybe 20 offices in 6 or 7 countries.
Company culture is open and there would be no problem pilot testing the tool (thanks for the answer below, already +1d)... but the real question is (in capital letters):
HOW DO YOU CONVINCE MANAGEMENT AROUND ALL THE OFFICES OVER THE WORLD THAT ITS A SANE THING TO DO AND WILL ACTUALLY BRING HAPPINESS AND PRODUCTIVITY TO DEVELOPERS? (say pilot testing and showing it works is just one part of the answer).
Elaborating on the context...
Does it make sense to make the switch?, yes (note: current SCM is Perforce). I've witnessed several sources of frustration classic to centralized source control management, including:
People accidentally breaking other's builds or stepping on each others' toes while submitting code revisions.
This is not often as the responsible must wear a pink hat (hilarious stuff) until the build is fixed, but the hat is still there, and when builds get broken it affects the other offices around the world.
DVCS to the rescue: Builds are now broken in a single office, people lose the fear to use version control and can actually second-guess themselves after or check with a peer by sharing their changes easier and not necessarily with the rest of the group.
Unnecessary bureaucracy when it comes to granting access (e.g. looks like everyone is granted access to most of the code).
There is a dedicated group of admins who take 1 to 3 days to grant access to the code, meanwhile other devs must ask their peers for the code just to look at it... but AFAIK, the often wait instead.
DVCS to the rescue: Administration does not have to be centralized on a little group of overwhealmed people, new employees get the code from the project's responsible (1st level) or a peer with repository access (2nd level) who could even review their code and submit it along with his/her changes.
Complaints with regards to slowness due to network latency. Not that directly, but sometimes a) The perforce server is down, b) Internet is down, c) Internet or perforce server is slow. Yes, not that often, but it is annoying enough to kick you off your train of thought sometimes.
DVCS to the rescue: When using the DVCS you obviously don't need a network connection. Worst case scenario?, share your changes over LAN or sneakernet (with patch queues).
Trouble when trying to collaborate with external providers that do not necessarily belong to the organization. This happens often enough and security is a concern here AFAIK, and clients suffer from the access bureaucracy.
DVCS to the rescue: So granting access to a subrepo here would be the ideal solution here... also, clients themselves could use version control among themselves without needing to setup their own server and they would be able to integrate better to the internal workflow as currently Perforce access access to the local network, and thus more bureaucracy which is not necessarily security here, as external collaborators still have access to thumbdrives and email. Actual security would be having externals work in situ... in a dungeon or something, and grope them à la TSA on their way out to make sure they are not getting the code out.
Workaround to integrate modules from other repositories. Requires additional maintenance/effort from the developers. *These guys actually wrote themselves (I think) a plugin to make perforce fetch files from other repositories in other parts *
DVCS to the rescue: Their solution looks a lot like the mercurial subrepo feature, wich uses a file (.hgsub) to indicate what code goes where, but they have to maintain the other repositories' states in the same file (which is done separately and automatically by mercurial in the .hgsubstate file).
Working with the source code requires to mark files for edit in advance. This adds an annoying extra step IMHO. If you don't do this the file will be in read only mode and you will not be able to edit it on your IDE, also, this IMHO makes the local copy prone to low integrity. This trait of perforce makes me think there was a lazy developer that didn't want to make the client check the files against the repo before versioning the changes. It also makes me think/personify Perforce as an idiot paranoid that says "DONT CHANGE THE FILES WITHOUT TELLING ME OR THE SQUIRRELS WILL COME AND EAT ME!!!".
DVCS to the rescue: Well... I guess any other SCM software knows there are no carnivore squirrels.
Little project integrity in developers' machines (see previous point; its harder to add changes without previously indicating them to Perforce). You don't need a DVCS for this... but if you make changes locally and for some reason forgot to add them, you are going to have a hard time detecting it. Once you detect it there is a two step command line instruction thing I saw somewhere to detect changes you did without telling Perforce.
Given that context what would you say is the best way to... ?:
- Know/demonstrate if the migration would actually benefit the employees and the company.
- Ease the embracement of change, or at least make it look like its worth the effort
- Not complicate others' jobs.
- Convince management worldwide.
- Avoid making the integrator's job a royal pain.
My second question (and focusing on the last point) I've always been a DVCS evangelist mainly because it eases the work and collaboration between developers... but up to this point I've never been faced with having to consider the integrators' perspective (the one in charge of coordinating teams' source code, creating and releasing the builds... from across the globe) who at some point might have to face two SCM sources or at least the migration itself. Then, how can the migration process affect integrators the least?.