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

Subject: [boost] Not Losing history (Was: [git] Boost.Build location_
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-12-28 09:41:56

on Fri Dec 28 2012, Tim Blechmann <tim-AT-klingt.org> wrote:

>>> > I'm sorry but projects way bigger and complext than boost handle entire history
>>> > and use full code (Linux... for example)
>> Right, but those projects aren't being split into hundreds of individual modules
>> which will often coexist in separate repositories on the same machine.  Always
>> storing the full history of all of Boost in each of those individual repositories
>> doesn't make sense.  Part of the point of this transition is to make development
>> less encumbered for everyone, and that would have the opposite effect.
>
> isn't there a middle way between `lose all history' 

Stop.  We are not proposing to lose all history.  

> and `keep all history'? 

In fact, we are proposing to keep all history.

> i didn't follow the whole discussion, 

I suggest following it more closely.  This alarmism about losing history
has gotten seriously out-of-hand, IMO, and the only way to bring it
under control is for people to pay close attention to what's actually
being proposed.

> but from my understanding the new layout for a lib `foo` is basically
> the content of libs/foo and boost/foo moved to include/boost/foo.

Not exactly, but the moral equivalent.

> so isn't it possible to rewrite the history in a way to keep the the old
> history, but filter out everything which is not in libs/foo or
> boost/foo? then each modular repository would have only the history
> relevant for that specific lib.

> that should leave the resulting repository at an acceptable size, but
> keep the history that is relevant for the individual modules ... has
> this been considered or are there arguments against this approach?

Please re-read
http://article.gmane.org/gmane.comp.lib.boost.devel/237389/
where I called this "modularizing the past."  We can do it, but I have
some concerns.

-- 
Dave Abrahams
BoostPro Computing                  Software Development        Training
http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost