We have a deadline of April 9 for some delivery of code. If the switch could happen after that we have no issue.
From: Matt Leotta [mailto:firstname.lastname@example.org]
Sent: Tuesday, March 05, 2013 4:04 PM
Subject: [Vxl-maintainers] VXL svn to git migration plans
Our VXL version control survey in January indicated strong interest in moving from subversion to git. We have been discussing at Kitware how best to make this transition. Brad King will be doing the conversion work. He still has files from the CVS to SVN conversion he did several years ago and plans to use them to construct an even more accurate representation of VXL's history than is current represented in VXL's subversion repository. Brad can have the conversion ready by sometime in April, so we just need to pick a transition date in April (or later) on which we stop committing to subversion. We will, of course, need to update the website, dashboard builds, etc. at that time.
Converting the VXL history to git is the easy part (at least for Brad). The more difficult part is deciding how we want to use git to improve our workflow. There are many workflows that git can support. These workflows can make the release process easier, improve the stability of the master branch, make it easier for outsiders to contribute, improve code review, improve feature testing, etc. However, since several key maintainers are not experienced with git, we feel the best course of action is to switch to git but continue a workflow that is very similar to our current one, at least at first, in order to give all maintainers time to become comfortable with git. In the short term, we will use git in much the same way we use subversion now, specifically:
1) The official repository will continue to be hosted at Sourceforge with the same user accounts, mailing list, website, etc. However, this does not prevent users from working with clones of the repository at GitHub or other hosting sites and later contributing back to the official repository.
2) There will be a single integration branch named 'master' that replaces the role of svn trunk.
3) Releases will be made by tagging a commit on master.
4) You can, if you choose, use a rebase workflow that is similar to how we work in subversion to directly apply commits to the head of the master branch. Alternatively, you can create topic branches off of the master branch and merge them back into master when they are ready. Details of the specific command syntax will be provided in a future e-mail.
Brad will be adding some server-side git hooks to enforce that the VXL history maintains an organized shape by allowing the master branch to be modified only as described in item 4 above. For those that know git, the hooks will enforce that the previous HEAD of master is reachable through a traversal of the first parents of commits. This prevents backward merges where the master branch is merged into the topic branch and then pushed back to master. Such backward merges make the history hard to follow.
Let me know if there are any questions about the conversion or if there is a problem with the April time frame. If there are no issues, we will lock down a specific date as we get closer to April.
Matt, Brad, Amitha