Re: [boost] Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)

Subject: Re: [boost] Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2010-12-27 00:27:46

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