on Thu May 23 2013, "Jürgen Hunold"
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