There has been a lot of talk around the office the last few weeks about source control management. Since I have been at Edmunds we have always used Perforce as our version control system. It seems to work for most users, and we have even used it as the storage engine for our content management system.
However, Perforce does have its problems, the one that I find most annoying is that the state of my local repository is stored on the server as part of my workspace specification. This "feature" causes us to implement a number of hacks within our CMS to support our centralized publishing service. This service can publish content from any branch or any label. The way workspaces handle keeping track of versions means we do a lot of work to allow the central service to meet our needs. Our first implementation used Subversion, which has its own set of problems, however, one thing we did like was that we did not need to sync to disk for anything we could request a specific version of a file from the Subversion server directly and send it out over our publishing bus without ever hitting disk. workspace specification.
Along comes Git. Several of our developers have been using Git on their own using git-p4 to keep their repositories in sync. There are several features of Git I find interesting. The primary feature I like is the ability to have multiple repositories. We've struggled for a long time trying to figure out how to implement an open source type model whereby developers become the curators of code bases. The goal is to ensure that an API stays true to its intentions and does not accumulate too much cruft. We've never come up with a good way of ensuring that the lead for an API is informed of changes, and Git's repository model seems like it would be a good fit. A lead for an API would have the authoritative repository for that API and only that repository could push changes to the central build repository.
Moving a large development group to a new source control system is a lot of work. There is training and tooling that needs to be created and moving our code and build systems would be a lot of work. I'm thinking that we could use git-p4 to have a single team test it. We're starting a new green field project in the next few weeks, I just need to convince the leads that this is a good additional risk to take on. I also have to research the git java APIs to ensure that the functionality we need for our CMS is supported as I'd like to keep one source control system in use.
