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-26 09:31:37

Sorry about the long Hiatus, I meant to get back to this email, as
there are some points raised that need to be addressed. That said,
please see below:

On Sun, Dec 19, 2010 at 12:43 AM, Lars Viklund <zao_at_[hidden]> wrote:
>>>> On Fri, Dec 17, 2010 at 9:34 PM, Lars Viklund<zao_at_[hidden]> Â wrote:
>>>>> Maybe you can adapt to the conventions of the real world, or use
>>>>> git-svn?
>
>>> On Fri, Dec 17, 2010 at 22:19, Dean Michael Berris
>>> <mikhailberis_at_[hidden]> Â wrote:
>>>> Which real world are you talking about, the one that I live in where
>>>> nobody uses SVN anymore and instead use Git for large open source
>>>> development projects? :)
>
>>Am 18.12.2010 09:47, schrieb Scott McMurray:
>>> Probably the "large commercial software company" world where the
>>> source control is so bad that branches get merged once every two weeks
>>> at best, and all checkins are blocked for over 24 hours when they do,
>>> so multiple releases get worked on in the same branch just to avoid
>>> the merging headaches.
>
> On Sat, Dec 18, 2010 at 03:46:30PM +0100, Oliver Kowalke wrote:
>>I think we should stop this talk - if desired you can start a new thread
>>with this topic.
>
> I apologise if the term "real world" was misunderstood, but I'm rather
> tired of when people come in from the outside, implying or demanding
> that a project should change their version control, build system or
> favourite bikeshed colour, just because they are used to something else
> (possibly "better") from elsewhere.
>

Actually, I don't know if you've been around enough to say who's
coming from the outside. Oliver and the others pushing for Git in
Boost aren't from the outside -- they've been contributing countless
man-hours testing, patching, and helping maintain the Boost C++
Library "from the inside".

The choice of whether the current system is sufficient is not made by
some committee or some handful of users that get to decide whether the
system is sufficient or otherwise.

> 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.

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.

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 -- as opposed to the way Git or Mercurial allow for
history merging/archiving to be achieved. This means Subversion
actually works against the project as opposed to with the project.

> In the end, the version control you choose is rather tangential. As long
> as it's sufficiently competent (which Subversion in my eyes is), you'll
> survive.
>

I think you haven't been looking at -- or are ignoring -- the problems
that Boost is already having when it comes to making the development
effort more scalable.

> 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.

> Remember that no tool is isolated. Changing from Subversion to
> <whatever> would result in many changes propagating to how test runners
> are set up, rewriting of commit hooks, modifying Trac (if possible)
> (although the SVN functionality is disabled there for now), requiring
> adaptation of any entity out there that use Boost's repositories in any
> way, including externals, build scripts, CI environments, etc.
>

Well, see, all these things you mention are really tangential to the
issue of whether you're using Subversion or Git.

Trac can be (and I think, should be) abandoned for something that
reflects better the workflow that Boost would want to encourage and
that performs better on the machine that is available to it. If the
solution is hosted for Boost then I would say it would be better.
Migration is always going to be an issue, but it's a mechanical issue
in reality. People just have to decide to do it, and then do it.

The commit hooks can be ported (quite easily if I may say so myself):
http://www.kernel.org/pub/software/scm/git/docs/githooks.html if there
was really enough momentum towards getting Boost from Subversion to
Git. The regression test runners could very well just change the
commands they use in the script -- instead of checking out, you'd
clone, and instead of updating, you'd pull.

All these things you mention are artificially made to look "hard"
because it's all a matter of migration really. The "hard" part is
accepting that there are better solutions out there already.

> And of course, having to have the mirrored Subversion repositories up
> for years, as you can't really 'flag day' such things.
>

I don't see why it can't be flag-day'ed. Linux made the move from the
proprietary system to Git in a drop of the hat. I don't see why Boost
won't be able to do the same.

And if people really wanted to get it via Subversion for some other
reason, someone else can definitely mirror the changes from Git to the
Subversion repository. Of course I'd say "good luck" to that effort
and maybe people who are still stuck with Subversion deserve the pain
of having to deal with it anyway. ;)

Happy Holidays everyone! :)

-- 
Dean Michael Berris
about.me/deanberris