DVCS and Perforce: "Two great tastes that taste great together!"
So goes the old line in the then-ubiquitous Reese's Peanut Butter Cups television commercials. If this is unfamiliar, revel in the famous peanut butter/chocolate collision.
Today a similar story is playing out in many companies as they discover the synergistic relationship between centralized and distributed SCM tools such as Subversion with Mercurial or Perforce with Git.
The initial creation of the hybrid distributed and centralized SCM environment is not often planned- it occurs as the fortuitous result of developers adopting DVCS tools such as Git on their local systems. This adoption of local VCS tools then can provoke a response from the administrators of the centralized tool, much as in the peanut butter/chocolate discovery.
"You got your centralized in my distributed!"
Imagine a developer coming from an educational or open source background using a DVCS and starting a job at a company with a strong release management process built around a centralized VCS.
The newly hired developer is faced with the unpleasant prospect of giving up a DVCS tool that powerfully enables their creative and productive powers. To make things worse, they are likely exposed to business processes that seem to hinder and disrupt their workflow. These processes were put in place to manage a complicated release and deploy process, but that isn't something they are exposed to very often. They rebel. And so they start using one of the integration tools that populates their local DVCS with files from the central system, and later pushing changes back to the centralized system.
It is this conflict between DVCS autonomy and centralized control that is the genesis of a hybrid distributed/centralized environment. Tools like git-p4 and git-svn allow the developer to export their work to a local DVCS repository. Now they have access to their favorite DVCS features, and can push back into the centralized environment.
But that's not the end of the story, because the centralized environment is impacted as well.
"You got your distributed in my centralized!"
Now imagine an SCM administrator finding out that developers by the hundreds are taking source code from the centralized SCM and exporting into DVCS repos. Is that local work backed up? Will this DVCS tie into the continuous integration tool and test suite that the developer wants to use? Are the developers using DVCS to circumvent important business processes?
Interviewing the head admin at a large Perforce customer, I could hear the fear in his voice as he told me he probably would end up being responsible for officially supporting an internal Perforce-Git gateway pioneered outlaw-style at a remote site. Would it scale? What are the unknowns?
Both centralized and distributed tools have proven their mettle for the types of work for which each excels. Is there a way to combine these two great tastes?
"Two great tastes that taste great together"
The strengths of both centralized and distributed version control tools have great potential to work together productively in a hybrid environment. On the local side, developers can use their coding tool of choice, and on the centralized side, admins can exercise the business processes, scalability, security and audit-worthiness of an enterprise-grade system such as Perforce.
It's important for an SCM to meet the needs of as many potential users as possible. For companies desiring a single-product solution, Perforce is creating P4Sandbox, which brings the most popular features of DVCS to the developer, enhanced with special Perforce-only technology. For those customers that need to provide solutions for Git and Mercurial users, Perforce is looking into robust integrations that facilitate using DVCS tools effectively as front-ends to Perforce. Or if you are satisfied with the simpler and more standard centralized workflow, Perforce continues to provide a rich set of traditional clients and client integrations.