Re: [boost] Git Modularization Review no vote heads-up

Subject: Re: [boost] Git Modularization Review no vote heads-up
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-05-23 09:44:44

on Thu May 23 2013, "Jürgen Hunold" <jhunold-AT-gmx.eu> wrote:

> Dave wrote:
>> if the consensus is that things should be rearranged in the
>> build repository, we can do that.  We just need clear and explicit
>> instructions that cover what to do with *all* the paths that have been
>> used in Boost.Build (including branches and tags) throughout time.  As
>> you can see from
>> https://github.com/ryppl/Boost2Git/blob/master/repositories.txt#L2261
>> and following lines, just preserving the existing structure was
>> nontrivial.
>
> That one starts with
>
> repository build : common_branches
> {
>   submodule of "boost" : "tools/build";
>   content
>   {
>     "tools/build/" : "build";
>     "tools/jam/" : "jam";
>   }
>
> right?

Yes, but note that there are five or so "repository" declarations for
the build repo.

> So, this now creates "tools/build/build" with the contents of
> "tools/build" and "tools/build/jam" with the contents of "tools/jam"
> which is long gone. The former is wrong, as it does not preserve the
> current structure despite the thing you wrote above.

It preserves *a fragment of* the current structure *within the build
repo*.  That's presumably the important one.  I expect the submodules
themselves to have a future as independent repositories, but not
necessarily as submodules.

> I think that a one-to-one mapping like:
>
> repository build : common_branches
> {
>   submodule of "boost" : "tools/build";
>   content
>   {
>     "tools/build/" ;
>   }
>
> is the way to go now. If something goes wrong, 

It will, because we'd no longer be catching tools/jam throughout
history.  That will cause modularization to fail.

> please put "tools/jam/" somewhere else.

Yeah, that's not specific enough.  What is "somewhere else?"

We could put it in the "engine" /v2/engine/ subdirectory of the build
repository, but that would be utterly inaccurate for older history.  We
can also have it move into /v2/engine from somewhere else (as it
actually does in SVN), but again, what is "somewhere else?"

...and—just checking—do you speak for the Boost.Build project, or is
Volodya likely to countermand your requests?

> Btw. would
>
> repository build : common_branches
> {
>   submodule of "boost" : "tools/build";
>   content
>   {
>     "tools/build/v2" ;
>   }
>
> be the right way to move v2 one directory up?

That would move the contents of v2 to the top level of the build repo,
but it would also drop all the commits that historically went directly
into tools/build/ (Boost.Build v1 mostly).  Like I said, we need
decisions about where *everything* that was in Boost.Build—throughout
history—belongs.

> Yours,
>
> Jürgen

-- 
Dave Abrahams