Boost logo

Boost :

Subject: Re: [boost] Not Losing history (Was: [git] Boost.Build location_
From: Tim Blechmann (tim_at_[hidden])
Date: 2012-12-28 10:24:01


>> > 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, 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 ...

>> > 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 (e.g. IDE
integrations for annotations). 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) ...

tim


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk