Re: [boost] Git Modularization Ready for Review

Subject: Re: [boost] Git Modularization Ready for Review
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-05-07 00:28:16

on Mon May 06 2013, Niall Douglas <ndouglas-AT-blackberry.com> 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