Subject: Re: [boost] [git] neglected aspects
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-02-28 15:22:50
on Thu Feb 09 2012, greened-AT-obbligato.org wrote:
> Beren Minor <beren.minor+boost_at_[hidden]> writes:
>> On Thu, Feb 9, 2012 at 12:07 PM, Tim Blechmann <tim_at_[hidden]> wrote:
>>> for a project like boost, i'd therefore suggest to avoid submodules. the
>>> advantage however is that the full git repository of boost is few hundred mb
>> Submodules are probably misunderstood and misused most of the time. I
>> think it was not meant to be used to have separate repositories for
>> sub-part of the projects and a everything evolving together in sync. I
>> see the use of submodules more like integrators would do, retrieving
>> specific revisions of various sub projects, and testing these versions
>> alltogether. Whenever parts integrates well, the submodule versions
>> that work fine together are frozen in a commit.
>> This is not very usable if you try to develop directly in the "main"
>> repository that has the submodules.
> I think that's right.
>> For Boost, I would say it could be used and even a powerful tool for
>> integrating libraries together, testing them and managing release
>> lifecycle, but could hardly be used for day to day library
> I would recommend using git-subtree. It's the submodule-like tool more
> appropriate for what boost is: a collection of project units that can be
> built and tested independently but also make sense as a cohesive whole.
> git-subtree is getting integrated into the official git repository now
> and should be available in the next month or two. Of you you can always
> get it here:
I don't think git-subtree is the right tool for us. Suppose libraries A
and B both depend on libraries C and D. It would IMO be a disaster if
the repositories for A and B each included the source to C and D.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com