on Mon May 06 2013, Niall Douglas wrote:

...

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?

Depends what you mean by hand written (there's a lot of automation involved), but yes.

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).

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).

Which is exactly the right behavior, except the silent part (although I'd be surprised if someone hasn't fixed that by now) 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.

Also, how is Boost going to manage dependency breakage across multiple submodules?

What is "dependency breakage?"

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.

I can see it becoming quite easy for submodules or branches or forks thereof to get out of step with one another.

That's a *good* thing. We're trying to decouple. Most libraries will be developed against the previous release of their dependencies.

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 don't have any idea what you mean here

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.

Beman has been working on the big picture doc. Beman? -- Dave Abrahams