DVCS isn't just for OSS anymore... Enter the DVCS Enterprise [Must not insert 1701 joke here...]

InfoQ - Distributed Version Control Systems in the Enterprise

"Every major Open Source project worldwide has already embraced Distributed Version Control Systems (DVCS), will enterprises be next?

Intro

Circa 2004 the world of version control (we can also call it Software Configuration Management (SCM), and while it is not exactly the same, most pragmatics among us will say they’re quite close) lived in a status quo. Version control had reached the point where it was just a commodity and the goal was to have one, no matter which one.

ALM Packages (Application Lifecycle Management) that wrapped version control were the ones delivering the core value to the projects, especially in the enterprise. The trend was management oriented, process driven and control centric.

And then everything turned upside down.

The Linux Kernel hackers needed a new version control system and they begged their über-guru, Torvalds, for a solution. Git was created, a hacker oriented tool to deal with the fast-changing, collaboratively-developed Linux Kernel sources.

With this, version control switched from commodity to productivity booster; The revolution had begun.

What is distributed all about?

Simply put: DVCS moves the project versioned repositories from a central location into each developer’s machine.

...

The enterprise question: why should I care?

So far the main benefit of DVCS seems to be getting rid of the central server and hence the potential slow networks across the Internet. What’s the benefit here for the enterprise?

Most enterprise developers will think, "Well, I work on a 1Gbps LAN connected to the main version control server. The connection speed is so high that the network time is not even in the equation, and I benefit from the server huge processing power to make all my version control operations fast". They’re right, since that’s the main reason behind client-server architectures and even the cloud, ultimately.

But, the situation described above doesn’t always match reality, at least not for many software development teams in enterprises. The reasons are:

• Having teams in different locations collaborating with each other is more and more common. It doesn’t just happen in big companies, even a 30 developer team can be distributed across different locations in different cities, countries or even continents. It sounded close to science fiction decades ago, but it is today’s reality.
• Companies struggle to find talent and more often than not they hire the best developers wherever they live. Working from home, is also a reality enterprises face.
• Outsourced teams in separate locations, sharing some of the requisites of internal distributed teams but normally imposing strict access policies to the repositories to keep projects coordinated.

What can DVCS do here? Let’s consider the case of a team with members in different locations as Figure 6 shows. There is a main site, where the central version control server is located, probably the first existing location in the company. Developers have a fast network there, and they’re happy working centralized.

Then there’s a second site, with more developers, connected to the main site through a VPN across the Internet. While their local network can be even faster than the one at the central site, they’re frustrated by the time version control operations take since each roundtrip has to go to the distant central server.

Then there’s the developer working from home, with a network connection that can be at times slow and unreliable.

Two thirds of the sites are losing productivity and motivation due to the centralized setup.

...

..."

You know what? If we could just get businesses and enterprises finally off of SourceSafe I think we'd have a win, let alone onto something like a DVCS (I think . That said, if you have a distributed development team, DVCS should be something you take a long hard look at. If you are all in the same building, on the same network, I personally think DVCS is overkill. Sure it's the new shiny and all and that's one reason I hesitate... Remember when the new shiny was PVCS? Then CVS? Then SVN? Now it's Git. What will it be tomorrow? [Insert grumpy old man, "who moved my lawn, get off my cheese..." statement here].

Yet another way to look at this change is that's it's agile like continuous improvement (that and if you can't handle continuous change, being a dev is the wrong thing to be...). in the end, when all is said and done, if I had dev's outside of the building, I'd look long and hard at DVCS... It does look like the right (well right'er anyway) tool for the right job.