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

Subject: Re: [boost] Not Losing history (Was: [git] Boost.Build location_
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-12-28 11:02:47

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

>>> > 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.
>
> well, i *did* check the history of the libraries at github, 

That's not what I'm talking about.

> which contain a lot of `latest from svn' messages, which is not
> exactly helpful when annotating sources or reading log messages
> ... but having lost my history when importing my libs from git into
> svn, i personally don't really care ... it could however be an issue
> for people working on older libraries ...

Those repositories are not an example of what you'll see eventually.
The history in those repos is entirely artificial and will be blown
away.

>>> > 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.
>
> keeping the history in an archive and outside of the new modularized
> repositories *is* the equivalent of loosing the archive for development
> purposes, as it cannot be used during the development workflow 

No, that's wrong.  After the appropriate "git replace" command it's just
as though the history was included in the first place.

> (e.g. IDE integrations for annotations).

I don't know what you mean here.

> of course, a modularized history is not `reality' and we won't be able
> to bisect issues for example or checkout specific tags ...
>
> iac, i'd rather have a `modularized past', knowing where certain code
> comes from and why it is there than a fully working `past' (if this is
> required, one can always go to the archive) ...

As noted earlier, we can create a "best effort" modularized past.
However, there are some caveats.  For example, some files have probably
been moved around in ways that could cause that history to appear to
lose the file in any given modularized repo, while it shows up in some
other modularized repo.

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