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.