Github Migration

Migrating from Sourceforge to Github

As BRL-CAD migrates its hosting platform from Sourceforge to Github, there are a number of complex steps that will need to play out.

Currently we are in the preliminary stages, exploring available tools, conversion techniques and identifying the necessary steps. Once we are ready, a series of events will occur in succession to finalize the move. This page is intended to identify and organize those steps so the migration can proceed in an orderly manner.

Version Control History

The most difficult and important of the conversion steps is the migration of BRL-CAD's version control based source code history from Subversion to Git. The process as it is finalizing (documented in detail in the BRL-CAD repository itself in the misc/repoconv sub-directory) will take a number of weeks to run, and will proceed roughly as follows:

• Finalize the email addresses and names used to map Subversion accounts to Github accounts. (Once the final conversion begins, these user identities are "locked in" to the git history and cannot easily be changed - they must be fully ready before the process begins.)
• Perform the initial Subversion -> Git process as outlined in misc/repoconv. (Est. 2-3 weeks to complete, once begun.)
• Lock the Sourceforge Subversion repository into read-only mode.
• Run a final update to pick up any commits made during the initial conversion process.
• Run the svn-fast-export process to generate the secondary git repositories for projects (geomcore, rt^3, etc.) other than the primary BRL-CAD repo in the Subversion repository on sourceforge.net/p/brlcad. (This process is much faster than the main conversion, and shouldn't take more than a few hours.)
• Upload all of the repositories to the github BRL-CAD project.
  • See the NOTES file in misc/repoconv for more details on this process.
  • In particular, the git notes with SVN repository conversion information will need a separate upload step.
  • Once "live", we can no longer alter the git history without potential impact to other developers - a git history rewrite (which any change will require) is guaranteed (unlike SVN) to be user visible and disruptive.
• Test checkout from the new repositories on github.
• Announce the change on the email list and update the website links.