(Keeping two revision control systems around is a bad idea. It doubles the maintenance burden, doubles the points of potential failure, and saddles us with maintaining the old system even if we transition to yet a fourth revision control system down the road. If we made the transition, we would have to make it completely, which means figuring out ahead of time how to handle referring to specific revisions, both old and new. --ANR)

There is a movement within the Parrot development community toward switching to a git as our primary version control system. Most of the objections to git have been addressed and the largest remaining technical problem is backwards compatibility. Various facets of the Parrot project have direct links and references to subversion revision numbers, e.g. on the Trac site, in the source, in mailing lists and probably elsewhere. We don't want these to break. That means that as part of the transition to Git, we'll need to ensure that current links to subversion revisions will continue to lead to a page which displays the correct changeset.

A few different options exists to allow Parrot to move to git while maintaining link backwards-compatibility. The first option is to use a single Git backend to Trac. The second option is use Trac with multiple vcs backends, i.e. read-only for subversion and read-write for git.

Trac with a Single Git Backend

This space unintentionally left blank.

Trac with Multiple VCS Backends

A small problem exists in the fact that Trac isn't meant to have multiple version control backends. There's a solution:

•  This tiny patch allows a Trac project to have a sub-project.
• The sub-project can be configured to use the same db as the parent project, propagating permissions and user info.
• Trac  allows navigation items to be customized.
  • A plugin allows them to be  added.
• A more or less usable  Git plugin exists for Trac.

Using these tools, here's a possible plan:

• Keep Subversion as the version control backend on the current Trac project (the parent).
• Add a subproject (the child) which uses Git as the vc backend.
• Make the following changes to the the navigation items ("Wiki", "Timeline", etc at the top of each page):
  • Change "Browse Source" to "Browse svn" and add a "Browse git" item to the parent.
  • Make "Browse git" point at the child project's source code browser.
  • Add "Browse svn" to the child project, point it at the parent project's code browser.
  • Make all navigation items in the child project point at the parent.

This would allow Git and Subversion to integrate gracefully with Trac and will preserve links to Subversion revision numbers. There are still some holes to fill in but that's more or less the plan. I (cotto) will make sure all the pieces exist and can be made to fit together before seriously proposing anything.

remaining issues:

• nice urls
  • make code browser urls look better ( parrot/svn-browser/... instead of parrot/p/parrot-git/browser)
  • make git changeset urls look good (parrot/git-changeset/102fe62b8 instead of parrot/p/parrot-git/changeset/...)
  • the IRequestHandler and IRequestFilter interfaces may be helpful here ( link)
  • have the child project generate nice-looking links
  • A small custom plugin may be required if none exists.
• It might be a good idea to add a notification to the svn code browser that informs users that active development no longer happens there.
• read-only access to the svn repo (marginally useful, mitigated by keeping a mirror on github, which allows svn access to git repositories)
• git trac plugin is inefficient (this is mitigated somewhat by the possibility of using github as a supplementary tool)