Feature Description

OpenNMS SVN is slow, and is not very well suited to our new branch-heavy development methodology. Moving to Git gives us the opportunity to use a modern, distributed VCS which is fast, and branch-friendly.

Why Git is good:

• fast
• conducive to creating and sharing data between multiple active feature branches
• easy to "package up" large amounts of branch changes into a single feature commit
• work offline!

Research Required

The first step is creating a Git Investigation Specification so we can determine what our requirements will be for the actual transition.

Acceptance Criteria

• Have multiple branches tracking stable and unstable development, as well as releases related to those branches.
• Have feature branches based on other development branches.
• Be able to easily share feature changes between developers (all committers, not just TOG).

Requirements

• Development Branches:
  • branches/1.6-testing should be available as a Git branch that can be branched from for stable feature changes and bug fixes
  • branches/trunk should be available as a Git branch that can be branched from for unstable feature additions
• Stable Branches:
  • branches/1.6 should be available as a Git branch for creating releases and snapshots, and should be able to track changes in branches/1.6-testing
  • branches/1.7 should be available as a Git branch for creating releases and snapshots, and should be able to track changes in branches/trunk
• Feature Branches:
  • it should be fast and easy to create a feature branch from branches/1.6 or branches/1.7
  • it should be fast and easy to push feature branch changes back to branches/1.6 or branches/1.7
  • it should be fast and easy to share feature branch changes with other feature branches, if necessary
• Commit Notification
  • it should be easy to view changes on the web
  • it should be possible to post changes to an email list
• Documentation
  • it must be well-documented how to do the current process within Git (which has a very different command-line workflow)

Nice-to-Haves

• commit-time validation and checking:
  • compile validation
  • javadoc generation
  • lint
  • findbugs
  • test code coverage
  • unit tests?

Design

Conversion

The first step is to convert the current SVN repository to Git. We need to investigate the tools to do so.

Potential pitfalls:

multiple trunks

We have multiple top-level "projects", each of which have their own tags/branches/trunk -- make sure that the conversion tools handle that in a graceful way.

poor naming conventions

we have some old feature branches and other pre-feature branches with bad names. We should take this opportunity to make the names not suck.

svn externals

we currently use svn:externals for pulling maven/ debian/ and solaris/ into the build trees. Make sure git supports externals, or converts them in such a way to be useful.

Available tools:

• http://github.com/jcoglan/svn2git
• http://www.kernel.org/pub/software/scm/git/docs/git-svn.html

Automation

A number of scripts and other tools currently rely on SVN, including maven release plugin code in our POMs, and the nightly build scripts.

We also do regular integration test builds with Bamboo.

These need to be updated to support checking out from our Git repository instead of SVN.