|
Boost : |
Subject: Re: [boost] Not Losing history (Was: [git] Boost.Build location_
From: Matt Chambers (matt.chambers42_at_[hidden])
Date: 2012-12-28 10:53:04
On 12/28/2012 9:24 AM, Tim Blechmann 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.
...snip...
> 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.
>
> 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) ...
I have followed the whole discussion, and think the "modularized past" is an optimal middle ground.
A simple note somewhere, to the effect that commits made before X date are from the monolithic era
and are not expected to compile, would explain the situation to new developers.
I'm not a fan of git, but I totally understand that it's a necessary evil for a project as large and
with as many developers as Boost, so thank you for handling the migration. It will be interesting to
see how the modularization will play with my current usage of BCP to distribute the boost source
subset we use.
Thanks,
-Matt
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk