Hi, Let me give an informal report, as we never came to making an official one. Our task description was to see how to improve the workflow (which I would like to point out as it is different from choosing another RCS). What did we do: * We discussed various models of patch flow, like the gatekeepers model and completely decentralized models. To see whether there were any advantages to go beyond the centralized 1 on 1 relation that subversion gives. * We compared 3 VCS, of which Git and Hg are contenders (see my other message). * We discussed various parts of our system infrastructure that surround our migration. In the other e-mail I think Oliver and I gave away our discussion on Git vs. Hg. So that's going to be there. In the rest of the issue, I will outline the 'other' issues that we encountered. 1. Where do shared developer branches go? The issue is whether to keep our data ourselves, outsource everything, or do a mix. I *suggest* we keep the main branch and release branches ourselves, and outsource the developer branches to github/bitbucket. (which are both good tools). 2. What to do with the source browser in Trac? Currently, neither git nor hg can be browsed in Trac with enough speed. Either one need a serious rewrite in order to 'work'. We can of course, use a native source browser while we rewrite, or we can decide not to use it anymore. (The solution is caching, and it shouldn't actually be that hard to implement, though). 3. How to improve patch flow from Trac? We were discussing a command-line utility that pushes and pulls patches from Trac. Both git and hg are able to 'bundle' changesets and distribute them. This could be a solution to the problem where patches seem to linger longer than necessary. Basically that's the discussion. Now for migration path: if 1 and 2 are decided, we can start looking at what changes in server configuration we should make. Note that it is actually not that difficult. In essence the source tree has already migrated to both Git[1] and Hg[2] and it is available now. It would take some work writing some policy documents and tutorials to get people started. Regards, N> [1] http://git.haiku-os.org/ [2] http://hg.haiku-os.org/