
The current approach implements the view of Boost as a particular set of libraries ONLY built/tested/distributed as an whole.
My view is that is not scaling well and can never do so.
+1
Still, that doesn't mean we're going to be more nimble and scalable if there's no standardization of tools across Boost. Quite the contrary, IMO. I can imagine all kinds of problems coming up that are simply ruled out by using the same tools.
+1 from me, we must IMO have standardized tools - whatever we decide those are - otherwise what you're proposing is the complete fragmentation of Boost into something even more unmanageable than now. I still haven't heard from the git proponents, what's wrong with using git-svn to manage a local - i.e. distributed - git repository, and then periodically pushing changes to SVN. In other words working with git just as you normally would, except for having to type "git svn" from time to time? This isn't a rhetorical question BTW, I've never used either git or git-svn, so I clearly don't know what I'm missing ;-) John. PS, just looked at the git website, and it appears that us Windows users are restricted to either Cygwin or MSys builds? If so that appears to be a major drawback IMO.... OK I see there's a TortoiseGit, but it looks distinctly immature at first glance, and still depends on MSys (i.e. no easy integrated install)?