This page exists to document what needs to happen before Parrot's developers will feel confident about switching version control from Subversion to Git. See also GitObjections

Requirements

• Backwards-compatibility of svn revision numbers. We aren't patient enough to change all references in Parrot and Trac to svn revisions, so there has to be a way to figure out what changes a svn revision refers to. This can be done by maintaining a read-only version of the svn repository.
  • When importing a SVN repo into Git, we have the choice of adding markers to each commit which reference the original SVN revision. It sounds like we want this.
• Trac integration - We aren't switching away from Trac, so we need to be sure that there's a *mature* Trac plugin that can work with Git, either directly or via a third-party host like  GitHub. This needs to be researched carefully since poor or immature Trac integration could be a significant impediment to Parrot's progress.

Things To Think About

• svn-properties - What do we want to do with them? For the most part, they seem useless.

coke: when switching partcl to git I ripped these out and haven't needed them since. We might to investigate a branch in svn without them that we can merge to trunk just before the cutover.

• External dependencies - Currently NQP-rx is copied manually into the Parrot repo by pmichaud++ when the time is right. We could set up NQP-rx as a git submodule, such that when you check out the Parrot git repo, it would checkout a specific commit of the NQP-rx git repo in a subdirectory, such as ext/nqp-rx.

Coke: this might be nice to have; I know we could do this with svn/svn-externals but chose not to. We would certainly want the ability to lock it against a particular revision of the external repo. (This is indeed how git submodules work. You peg a directory to a specified SHA1.)