Version 6 (modified by dukeleto, 12 years ago)


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


  • 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.)