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

  • From: Adrien Destugues <pulkomandy@xxxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 03 May 2011 20:16:25 +0100

On the contributor side, this still isn't as simple as "svn diff".
It may be interesting, if it also replaces steps d and e. But Idon't
know if it does. Does github or gitorious offer a way to trac the forks
that were made from Haiku ? If so, how do we know which ones are ready
for merging in the mainline Haiku ? Are they ready ? Are they meant for us ?
You miss the real point here, which is that a DVCS allows you to update your
local changes to stay in sync with the trunk easily. That's where svn sucks.
As a result, patches get stale pretty fast and the required effort to
maintain them is so high with subversion, that people don't bother. In the
end, this means we lose potentially good patches.
I agree with that. The outcome doesn't really depends on the tools, but on the way we use them. svn alone is painful, but it's possible to use extensions to have local branching and so on (svk mostly does that, or is close enough). In the same way, hg and git offer a lot of features, and additional plugins/extensions, to get anything done.

The question is how we expect to work with patches now ? Possible answers are using github "forks", keep the current trac system and count on the patch contributor to keep his local checkout in sync and update the patch, or allow contributors to send their patches to some kind of "contrib" DCVS repo of our own with open access. Maybe there are other ways, I'm not familiar with DCVS uses so I'll let other people figure it out. There has to be a way that gets thing simple for both core developpers and occasional patch contributors. Which one is it ?
These are the questions I worry about : I'm ok with switching to a DCVS
for the ability to work on separate changesets, to do more things
locally before commiting to the central repository, the easier branching
and patch tracking. Enough discussion was spent on that, and it's
getting sorted out. Switching to a service like github, however, means a
lot of changes, and I wonder if we can handle it with our long quality
review process and our small developper team. Maybe we can first switch
to a DCVS, then later see if we need to do more ?
Github/Gitorious will not become a part of the core project, but it is a very
nifty way for all contributors (including core developers) to publically work
on experimental features of Haiku. If someone doesn't want to use it, no one
forces it upon him.

Of course. One thing I like in the current setup is watching a single RSS feed (commit feed provided by trac), or subscribe to haiku-commits ml to know about mostly everything that is hapenning in the small Haiku world development. If we switch to a distributed system using something like github, tracking this may become a lot less easier. I believe a local install of gitorious would provide some global rss feed, on the other hand. Maybe there are other solutions. Maybe there will be too much activity and I don't want to hear about some parts.

In the current system, we have an efficient way to see all the waiting patches in Trac. Take care of not losing that. It may be done in other ways, but knowing that 12 or more clones/forks of Haiku codebase exist around various servers doesn't mean we can track them easily. When we see them, we can merge them more easily, but I think we are going to have two problems : * people doing their clone, messing with it and never giving anything back : ok, I'm sure this already happens, at least the code would be online somewhere instead of sleeping on some hacker's hard disk. Good thing. * people doing their own clone, keeping it in sync and all, and coming after one or two years with a huge patch that changes a lot of things. Think of something like Stack&Tile. The merging of such a work would be made easier, but the code review process will not (it was not easy either with svn). Maybe we can think on how to improve this aspect as well ?


Other related posts: