Re: [boost] [svn/git/hg] Support for modularization of Boost?

Subject: Re: [boost] [svn/git/hg] Support for modularization of Boost?
From: Beman Dawes (bdawes_at_[hidden])
Date: 2012-04-04 22:06:39

On Wed, Apr 4, 2012 at 12:05 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>
> on Tue Apr 03 2012, Beman Dawes <bdawes-AT-acm.org> wrote:
>
>> As far as I can see, scaling Boost up to a much larger number of
>> libraries implies decentralization and decoupling, probably in the
>> form of per-library modules or something similar.
>
> Quite so.
>
>> Modularization seems to have been missed in the discussions of
>> Subversion, Git, and Mercurial. Do distributed version control systems
>> in general and Git in particular have any important
>> advantages/disadvantages over svn for highly modularized projects?
>
> Aside from the fact that boost is already modularized in Git, you mean?
> ;-)
> http://github.com/boost-lib

The fact that we already have both the history conversion problem and
the modularization problem solved using Git is no small advantage for
Git, but I'm also trying to see if there is technical advantage one
way or the other.
>
>> Please, let's not waste everyone's time with a rehash of general DCVS
>> vs CCVS pros and cons. We have beat that to death. Let's focus this
>> thread on modularization support, particularly as it applies to Boost.
>
> Well, let's see... I guess *if* you want to treat modules as
> sub-modules, Git is a bit more flexible than SVN in that you have both
> submodules (roughly like svn externals) and git-subtree (in the next
> release of Git, or a separate add-on until then), so you can choose your
> poison.

OK, so that's the technical answer I was looking for.

I'll read up on git-subtree so I can understand a bit better.

> However, I don't think we're (mostly) going to be using either of those
> technologies.  Instead, I believe we'll be using 0install to manage the
> interactions of related library versions, which will render most such
> questions moot.  A library developer will (mostly) be working with only
> one repository at a time, and the dependency management system in
> 0install will take care of acquiring the others.

Good. Dependency management is seriously worrisome, so having a
solution for that is another big step forward.

Thanks,

--Beman