[haiku-development] Re: Finally deciding on a new source control system for Haiku

  • From: Adrien Destugues <pulkomandy@xxxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 30 Apr 2011 22:54:31 +0100

Le 30/04/2011 21:50, Ryan Leavengood a écrit :
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.
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 :).

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

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


Other related posts: