Dean Michael Berris wrote:
As for version control, what does it matter if Boost uses Subversion, when you as a DVCS user can trivially use git-svn [1] to interop against the repository (in this case, the sandbox). You get to use your favourite toy, without affecting the existing infrastructure in any way.
Yes, it matters. Let me state a few reasons why:
1. Precisely because it's Subversion, a non-distributed configuration management system, the process of getting changes in and innovating is slowed down by the bottleneck that is the centralized source code management system.
Would you please specify a concrete example where innovation in a library that you personally is contributing to is slowed down by centralized version control?
2. Potential contributors to Boost that have to deal with Subversion from the outside through a hack that is Git-SVN is just a Bad Idea. If a library that is being developed to be made part of Boost has to go to the Sandbox, then the process of developing a library in a collaborative manner would be a lot harder. I've already pointed out the reasons for this in another thread pleading to get Boost development out of a centralized system and into a more distributed system.
Have you ever used git-svn in practice? I do use it daily, and it's not entirely clear whether git or git-svn is worse "hack".
3. Because of the central management that Subversion promotes, libraries that are developed by other people meant to be integrated into the Boost sources will have trouble moving the history of these projects into the Boost Subversion system -- nearly impossible if you think about it --
You *really* should use git-svn. It's trivial to push any line of history to any branch on any subversion server.
Of course, you may propose constructive criticism and suggest migration plans to other toolchains, with good arguments for why this is a good thing. See the mythical 'Ryppl' project, which aims to componentise Boost into a pile of Git repositories and some magical combination of scripts and CMake, aimed at letting you track exactly the versions of components you need.
Well, it's not mythical -- it's there, and the Boost Libraries have pretty much been broken up already. The CMake migration is taking a while and the only reason for that is there aren't enough help going into the CMake effort.
Actually, not quite. The primarily reason is that while CMake was originally touted as a turn-key solution, turning the key did not work. So much, that a Kitware engineer had to be brough in to fix issues -- and apparently haven't yet. - Volodya