Le 30/04/2011 21:50, Ryan Leavengood a écrit :
Not really. During the first half of the project, the students have to get their patches checked by the mentors before getting them committed to svn. Wether to use a branch or not is only decided by looking at the project itself : if it breaks a lot of things, a branch is better :).On Sat, Apr 30, 2011 at 4:34 PM, Sean Healy<jalopeura@xxxxxxxxxxx> wrote:Both git and hg are said to have big learning curves (although hg's is said to be smaller than git's), and I would expect that bzr does as well. The start of GSoC does not seem like a good time to force this learning curve on students who already have a lot on their plate with GSoC itself.Well you may be in the minority of students who have experience with SVN. So it could be argued that learning Git or Mercurial (hg) would not be that much harder than learning SVN for those with no experience in any of those tools. On the other side of the equation some of the other students may already be familiar with Git or Mercurial as well as SVN. I am curious what the plan is for GSoC student's code. I think in the past we made Subversion branches for students to work in. Though sometimes their work remains lost in those branches if no one takes the time to merge them in (though that is no argument against SVN since the same could happen with any tool.) I know in some cases students just made their own repos in other places, which I think is a bit silly when the Haiku project should be able to provide a place for them to work.
As for people using other tools, this indeed points to a failure of the current system. However, it only affects about 8 people a year, so it can be considered not too important. On the other hand, these people are our potential future contributors, and seeing them working elsewhere means something...
Anyway, this could be solved by creating branches for their work, the problem is it is difficult to merge branches in svn, and the task is usually done by the mentor. Students don't really see svn apart from checkout/update at the beginning.
When switching to another tool, we are going to experiment for some time and likely adjust our workflow to the new possibilities. If we do this just when new students get in, they can take part on the discussions, which is nice for integrating them. If we do it later, we have to write guides on the way we use the tools. DCVS being a kind of swiss army knife software, we are going to use only a part of them. Knowing which part is an important step in understanding the tool.
It's time for the switch. I think all (most ?) developpers agree on that. Tracking patches that get out of sync with the tree is taking more time than needed, handling the commits from the GSoC students by hand, messing with branches and merging changes around, are tasks that should mostly be done by the tools. svn has trouble handling them. The problem is (was?) to know which alternative is best for us. The commitee was setup to decide on that. The next step is flipping the switch, I think...Please note that my intention is not to express an opinion on a source control system, but rather on the timing of the switch.Thanks for your perspective. I'd be interested in hearing from other GSoC students in whether switching now would make things more difficult for them. Also I'm just one developer who would like to see things move forward on this issue and if I'm in the minority in a vote we may just end up keeping SVN for now.