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
> 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?
where I called this "modularizing the past." We can do it, but I have
-- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk