on Thu May 23 2013, Rene Rivera
On Thu, May 23, 2013 at 8:44 AM, Dave Abrahams
wrote: on Thu May 23 2013, "Jürgen Hunold"
wrote: Dave wrote:
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?"
branch = historical path = "jam/"
AFAICT, that doesn't work. tools/jam (or its equivalent) has appeared in many different SVN branches, including trunk. You can't just squash them all into one branch and come out with anything meaningful.
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.
Anything before v2 existed should go to:
branch = historical path = "build/"
As before, you can't meaningfully squash everything into one branch.
Or more descriptive..
1. Put anything that ever existed in the current build/v2/* files at the root of the new build repo.
Easy enough
2. Put anything else in some form of "historical" branch using the path from "boost-root/"
? There's no "boost-root/" in SVN AFAIK
as the path in the new repo. (I don't care that much about the actual branch names other than to tell that they are there only as history).
But since I don't know git sufficiently.. I don't know if that's practically possible. Specifically I don't know if one can follow history back across branches.
Branches in Git are merely (reference-counted) labels for commits, each of which is the root of a history DAG. When you merge branch A into branch B, you can follow history from B to the last commit on A when it was merged, and thence to all of that commit's ancestors. If no further commits are made to A, it looks like this: /--> A --> A~1 ... B --> B~1 --> B~2 ... B~N < \--> B~(N+1) --> ... If you mean something else by "follow history," I guess you'd better explain.
if it's not possible then I would say change #2 above to:
2. Put anything else at historical/jam, and historical/build in whatever branches you have now.
Are those (historical/jam and historical/build) supposed to be branch names or paths? -- Dave Abrahams