Boost logo

Boost :

Subject: Re: [boost] Losing history (Was: [git] Boost.Build location_
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-12-29 15:20:20

on Fri Dec 28 2012, Vladimir Prus <> wrote:

> On 28.12.2012 01:54, Dave Abrahams wrote:
>> on Thu Dec 27 2012, Beman Dawes <> wrote:
>>> On Thu, Dec 27, 2012 at 12:45 PM, Robert Ramey <ramey_at_[hidden]> wrote:
>>>> Hmmm.. Let's suppose for a moment that the modularization effort
>>>> resulted in a repository which didn't include the current history.
>>>> There's no reason that the old SVN has to go way. I guess it
>>>> could be made read only.
>>> Of course! That's been the plan all along, just as we didn't blow away
>>> the old CVS repo when we switched to SVN.
>>> The point at which SVN becomes read-only has been shown on the
>>> schedule and on the action plan right from the start.
>>> See and
>>>> It would also be convienient that
>>>> the web browsing feature be re-enabled.
>>> Good point. The load on the IU server should be a lot less after we
>>> switch to GitHub.
>> There will also always be the GitHub browser usable on the converted
>> history repository.
> These all sounds like poor substitutes for actual history. If I run
> "git log" in program_options checkout, I really would like to see all
> changes ever made to what is boost/program_options and
> libs/program_options in the current layout. I certainly don't expect
> that repository to contain entire history of Boost, and so it should
> not be 200+ MB. But I think conveniently looking at history is one of
> the primary use cases of a version control system. And one of the
> advantages of git was supposed to be effective storage of entire
> history.

Yes, and we can do that as long as it's clear to everyone that what
you're getting for isn't "actual history;" it's a modularized past.
There are a number of features of "actual history" (which is
monolithic), such as changes made across several modules at once, that
it won't capture.

> If we're going to require that I poke at some other git repo, or svn,
> or commit mailing lists, or anything else for such a basic task, then
> I suppose we can switch to RCS just as well.

Please, let's not be dramatic about this. It would be a step you
would take once for any given clone of a modularized repo. Thereafter,
it would work just as you'd expect.

I'm happy to go either way, as long as we are making the choice with our
eyes fully open.

Dave Abrahams
BoostPro Computing                  Software Development        Training             Clang/LLVM/EDG Compilers  C++  Boost

Boost list run by bdawes at, gregod at, cpdaniel at, john at