To Git or Not To Git

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.

Advertisements
This entry was posted in Development Tools, Java and tagged , , , , , , . Bookmark the permalink.

2 Responses to To Git or Not To Git

  1. Mark Walters says:

    Hey Paddy!
    I would fully use a trust policy leveraging the Promotional model, where you define a promotion graph from known special purpose git repositories. Using the policy where the end-points pull from a known controlled git repository. Any changes in those authoritative source repo’s would be controlled by access for their updates. Those source authoritatives would use the same standard RM/SCM promotional models policies usedin standard VCS, then your production systems would poll and pull any updates. Idea is to not put anything in the staging git authoritativites, which you don’t want public/publish; if you do, just push another version into the source points, let the end-points pull.
    I have used git repos in this way to manage production and pre-release environments regarding our VoIP solution built on centos, asterisk servers, agi code, apache code, and some OS based files up-to-date and sychronized. Works well in a scalable grid based solution to our VoIP Enterprise.
    And normally I push my changes via proto-types and well formed documentation. 🙂
    Hope all is well, miss you guys.

  2. Unicornryder says:

    Git has support for connecting to both svn and p4 as upstream repositories.
    As such the major benefits of Git such as:
    + Working offline with full commit history.
    + The ability to manage commit history.
    + Cheap local branching.
    + Easy way to locate changed files.
    Can still be leveraged without moving from an upstream P4 server.
    Not moving the upstream server really only has two costs.
    1. Can’t leverage alternate development models (Dictator – lieutenants)
    2. CI servers can only see P4 committed changes to (otherwise CI servers need to be integrated with both source control systems).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s