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@acc.umu.se> wrote:
On Fri, Dec 17, 2010 at 9:34 PM, Lars Viklund<zao@acc.umu.se> 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@gmail.com> 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