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: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-12-27 10:16:04

On Mon, Dec 27, 2010 at 1:27 PM, Vladimir Prus
<vladimir_at_[hidden]> 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