Re: [boost] Git Modularization Ready for Review

Subject: Re: [boost] Git Modularization Ready for Review
From: Alexander Lamaison (awl03_at_[hidden])
Date: 2013-05-09 13:12:34

Niall Douglas <ndouglas_at_[hidden]> writes:

>> > I'm far more confused as to why? Surely the conventional approach is to
>> > convert a SVN repo to GIT.
>> 
>> Good luck with that, given the way SVN "branches" (really directories)
>> have been used in Boost's history.  No automated tool is able to
>> determine how to map those things properly onto Git branches.  You can
>> see evidence of that in repositories.txt (look at the "build" repository
>> declarations for example).
>
> 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.

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.

What happens in a few years time when Git is replaced with the next big
thing?  Do we lose the history again?  And then again when that gets
replaced too?

>> You act as though we haven't been thinking about how to do this well and
>> working on it for years already.  We're quite well-aware how submodules
>> work.  The use of submodules by most developers is supposed to be a
>> temporary transitional measure, since modularization is designed to
>> allow you to work with only the parts of Boost relevant to your project.
>
> You have mistaken my confusion for criticism. I am not criticizing. I am
> confused.
>
>> > Also, how is Boost going to manage dependency breakage across multiple
>> > submodules?
>> 
>> What is "dependency breakage?"
>
> Generally speaking Git submodules are for loosely coupled relations because
> of how Git implements submodules. Some of Boost's constituent libraries do
> meet that definition (BPL, BGL, Math). Some do not, as they are too
> essential because so many other libraries depend on them (anything likely to
> enter the standard with TR2, the MPL, the PPL etc).

A blob that is sometimes needed but must be supplied is a problem.  A
blob that is always needed but does not have to be supplied is not a
problem.

> I fear that if modularization is taken to its logical extreme, you could see
> submodules get out of step with other submodules. You may of course have
> already anticipated this and have implemented something I haven't realized.
> As I said, I am confused.

Can you explain a bit more about what you mean by out-of-step?  The whole
point of modularising the code is to *help* modules to get out-of-step
and therefore be easier to develop and test independent of what other
Boost libraries are doing.  But perhaps you mean something else?

>> > Are you planning to keep headers in one monolithic repo
>> 
>> No
>> 
>> > but keep anything resulting in a DLL/SO in a submodule? Or are you
>> > planning to break out the headers into submodules too?
>> 
>> Yes; it's already done, modulo some expected adjustments due to the
>> review I am requesting.
>
> One solution is to require all findable headers to live inside the main
> Boost repo [1], and only implementation to reside in submodules. That keeps
> minds focused on dependency management.
>
> [1]: By findable I mean that when Boost library users do #include
> <boost/whatever> they get the main Boost repo version, not the submodule
> version. I absolutely would expect an automated tool to pull headers from
> submodules, check them for ABI breakage and push them into the main repo. My
> point is that some sanity check ought to be there.

I'm not following why you would want to do this.  Perhaps you can
explain what problem you are anticipating and how this would solve it?

I also don't get what 'findable' means.  What would a non-findable
header be?

Alex

-- 
Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)