With Atlassian and Perforce, Git goes enterprise
October 9, 2012 —
(Page 1 of 2)
Related Search Term(s): Atlassian, Git, Perforce
Today, Atlassian announced that it will offer Git as a source-code-management system in its Bitbucket code-hosting site, as well as in its Stash product. Stash performs SCM duties with an on-site hosted repository, and it is based on Git. It includes support for roles and permissions, and also includes a graphical user interface.
Just one week earlier, Perforce announced similar support within its eponymous SCM system. Perforce's strategy for integrating Git is to include it as just another dataset stored in Perforce. Thus, multiple Git repositories can now be stored in Perforce, and groupings of those code stores can be reconfigured, manipulated and pushed out as a freshly built Git repository.
Both of these offerings are compelling solutions to the proliferate problems with Git in the enterprise. Traditionally, Git has had problems managing repositories over 2GB in size, and tends to become slow to use after storage hits that mark. As a result, Git best practices encourage every project to be stored in its own self-contained repository. That means an enterprise hoping to use Git could expect to manage dozens if not hundreds of individual Git repositories.
Atlassian and Perforce both hope to solve this problem through centralized management systems and additional enterprise features layered on top of the platform.
“We are actually taking everything that goes into a Git repository and storing that in Perforce,” said Randy DeFauw, technical marketing manager at Perforce. “That gives us unique capabilities. We could take a big Git repository and split it into smaller repositories. We can push anything back out as a Git repository as well. We can easily create custom repositories. We can take anything you pulled in, whether it came from Perforce or Git, and you can pull out what you need in a new Git repository that has just what you want. If someone pushes a change from Git, we're recording that as regular changes in the Perforce side. On the other side, your git log command will look like normal Git history.”
Despite both companies claiming to be making Git into an enterprise-ready system, their approaches are fairly different. Emblematic of this difference is the comparable solutions to the 2GB problem in Git. Perforce manages this problem by storing non-code assets, such as art, in the standard Perforce SCM system, which has matured specifically to handle such large files. Atlassian's solution is to offer management tools for handling lots of smaller Git repositories.
“Since Git clones the entire repository to the local machine, the clone operation can be slow when the repositories grow beyond a certain size,” said Giancarlo Lionetti, group product manager for Atlassian's developer products. “We recommend not to store large binary files in the repository. The Git project itself is looking into solving the problem in the actual Git code, but best practices and other tools currently exist to work around this limitation. For example, you can manage files in a separate repository and then use Git submodules to pull them into your project in a more efficient way, and only check out the large repository if necessary.”