Re: [boost] Git Modularization Ready for Review

Subject: Re: [boost] Git Modularization Ready for Review
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-05-11 01:39:10

on Fri May 10 2013, Niall Douglas <ndouglas-AT-blackberry.com> wrote:

>> Niall Douglas <ndouglas_at_[hidden]> writes:
>> 
>> > Me personally I'd just chuck away any unmappable historical information.
>> > Chalk it up to a cost of transition. If they really need the history,
>> > they can go fetch it from the read-only SVN repo.
>> 
>> I see you've not been keeping up with the list lately ;) Daniel et. al.
>> suggested doing just that a few months ago and was met with such a chorus
> of
>> criticism, they didn't really have a choice but to fix it.
>
> Never actually was on this list, not ever, until recently as it's a lot of
> extra reading. Been involved with Boost for over a decade though.
>
>> Personally, I agree with the chorus.  After all, the point of a VCS
>> is to have a history of the code's evolution to a point.  The VCS, be
>> it SVN, Git, whatever, is just a means to get that history.
>> Jetissoning the ends for the means seems misguided.
>
> No, it's a cost of doing an upgrade. Those of you who ever migrated a large
> CVS to SVN  transition know what I mean: stuff gets lost, and actually it
> isn't important enough to preserve that it requires a quadrupling of
> transition effort when a read-only copy of the old technology repo is good
> enough. Distributed SCM is much more dimorphic again, and you *have* to
> accept some data loss.

Nothing important need be lost.  We're not losing any commits.  SVN does
represent merge information as an exact set of contributing commits
rather than as a chain of history, and trying to preserve all that
exactly would be... dumb.

> Let me put this another way: those who want no history loss ought to be the
> ones volunteering the additional time to preserve history. What actually
> happens sadly is then the argument becomes we must stick with whatever the
> old technology is, because people will choose a small reduction of
> productivity every day over fixing tooling once and for all

I didn't want to do the job of modularizing history, but now that it's
close-to-finished, arguing for someone else to do it seems... pointless.

> My only red line is corruption of past and present source code releases. It
> must *always* be possible to check out tag X and build release X. 

Which is why we're keeping a read-only copy of SVN.  Modularized
repositories are never going to reassemble to form an exact picture of
history, because several files from the same SVN directory need to be
sorted into different repos.

-- 
Dave Abrahams