On Mon, Dec 27, 2010 at 1:27 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
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?
Boost.Pool is one, and the other was Boost.Iterators. With Boost.Pool, there's no maintainer around (that I know) who's checking patches submitted to it and making sure the changes make it into the releases. With Boost.Iterators, it took a while to get a patch for an additional iterator implementation to get into trunk -- and I'm not even sure if my patch has made it into the release yet. And these are just the libraries I've tried contributing to. I'm sure there are other libraries out there like Boost.Serialization where the port to Boost.Spirit's Qi got bogged down because Bryce couldn't get commit access early enough to be able to make changes to the Boost.Serialization parser implementation.
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".
Yes -- and if you use Git like you use SVN, then you won't have problems. But if you're like me who has a lot of small changes checked into Git, multiple branches, and multiple integration points from different branches (and repositories) then you'll see how git-svn is a bigger pain to deal with than it is worth.
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.
No, sorry. If you have a ton of changes that are in SVN repository SVN-A, and a ton of changes that are in SVN repository SVN-B, then merging the histories of SVN-A and SVN-B turn into gobbleygook. Sure you can graft together histories and it would be a bad hack and you don't really achieve what you want in the end.
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.
Well, I'm not sure if you've followed the latest discussions that happened in the Ryppl ML, but basically what has already happened is: Boost has been broken up into multiple Git repositories, sync'ed with Subversion. The issue now is getting the individual CMake files in the Git repositories to be able to register itself to the bigger Boost distribution CMake configuration. CMake wasn't originally made to handle this specific use case. Now making this specific thing happen is what's taking a while. The other issue has to do with Ryppl's dependency management, but that's another can of worms in itself. Anyway, really, CMake has been a joy to deal with, except in the case where you have to do something that's out of the ordinary. What the modularized Boost effort is facing is really something unique that I don't think Boost.Build is even able to solve either. Of course you're welcome to prove me wrong on that. :) -- Dean Michael Berris about.me/deanberris