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