Re: [boost] Losing history (Was: [git] Boost.Build location_

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 <ghost-AT-cs.msu.su> wrote:

> On 28.12.2012 01:54, Dave Abrahams wrote:
>>
>> on Thu Dec 27 2012, Beman Dawes <bdawes-AT-acm.org> 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 https://svn.boost.org/trac/boost/wiki/MoveToModularizedGit and
>>> https://svn.boost.org/trac/boost/wiki/ModCvtSchedule
>>>
>>>> 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
http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost