Re: [boost] Git Modularization Ready for Review

on Fri May 10 2013, Niall Douglas wrote:

...

Niall Douglas 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