[boost] Git Modularization Ready for Review

Subject: [boost] Git Modularization Ready for Review
From: Niall Douglas (ndouglas_at_[hidden])
Date: 2013-05-06 12:12:13

> After substantial work, including massive changes by me and Daniel Pfeifer
to
> KDE's svn->Git conversion tool, we have captured every Boost SVN commit in
a
> Git repository.  You can view the results at
> 
>     http://github.com/boostorg
>     http://bitbucket.org/boostorg
> 
> Daniel and I are ready to accept your feedback on the results of
modularization,
> and especially your pull requests containing edits to the ruleset.  I will
the
> steering committee to establish a formal review period, though.

I'm a bit confused. This looks like a hand written map of parts of Boost SVN
onto multiple GIT repos. Am I understanding correctly?

I'm far more confused as to why? Surely the conventional approach is to
convert a SVN repo to GIT. Then people hive off their particular bits into
submodules as and when they themselves decide and they are ready. It looks
here that Boost has decided on skipping the intermediate stage and going
straight to submodules. That sounds awfully fraught: it also demands a lot
from those library maintainers not familiar with Git. Submodules are
extremely different to SVN externals - they're a very light link, and in
many occasions Git does not auto-update submodules even when you tell it
(i.e. it'll fetch, but silently not checkout head if it thinks you might
lose data).

Also, how is Boost going to manage dependency breakage across multiple
submodules? Are you planning to keep headers in one monolithic repo but keep
anything resulting in a DLL/SO in a submodule? Or are you planning to break
out the headers into submodules too? I can see it becoming quite easy for
submodules or branches or forks thereof to get out of step with one another.
I can see the present submodule heavy approach introducing a lot of anti-Git
workflow because those submodules inside the boostorg organization are
treated as special compared to other submodules.

I'm confused. Sorry. I'm probably not making any sense. Is there a design
rationale document somewhere? I can't see one up to date on Google.

Niall

---
Opinions expressed here are my own and do not necessarily represent those of
BlackBerry Inc.