I am OK with the date. Please update dashboard cmake scripts (vxl_dashboard.cmake, vxl_common.cmake) accordingly.
 

Date: Thu, 4 Apr 2013 14:29:32 -0400
From: matt.leotta@kitware.com
To: vxl-maintainers@lists.sourceforge.net
Subject: Re: [Vxl-maintainers] VXL svn to git migration plans

All,

Brad King has completed the conversion of the VXL history from subversion to git.  He also used direct conversion from the old CVS repository to get a more accurate representation of the earlier part of VXL's history.  The history will be updated to add the latest subversion commit's right before we make the official switch.  If anyone is interested in inspecting the history before it becomes official just let us know, and Brad will clone the repository to someplace publicly accessible.

We would like to propose May 1st as migration day.  On that day we will stop commits to subversion, update git with the latest subversion commits, make the git repository available at sourceforge, and continue all development using git.  We will also update the webpage and dashboards accordingly.  Are there any conflicts with this date?

Thanks,
Matt



On Tue, Mar 5, 2013 at 4:26 PM, Matthew Leotta <matt.leotta@kitware.com> wrote:
Joe,

That should not be a problem.  We'll keep that constraint in mind when selecting a date.

--Matt


On Mar 5, 2013, at 4:17 PM, Joseph Mundy <mundy@lems.brown.edu> wrote:

Matt,
We have a deadline of April 9 for some delivery of code. If the switch could happen after that we have no issue.
Joe
 
From: Matt Leotta [mailto:matt.leotta@kitware.com] 
Sent: Tuesday, March 05, 2013 4:04 PM
To: Vxl-maintainers
Subject: [Vxl-maintainers] VXL svn to git migration plans
 
All,
 
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.
 
Thanks,
Matt, Brad, Amitha



------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html
_______________________________________________ Vxl-maintainers mailing list Vxl-maintainers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/vxl-maintainers