...
- Put subsubpackages in their own repositories in Git; use some existing tool, like subtrees or subrepos, to keep track of the "real" structure
- Put subsubpackages in their own repositories in Git; use homegrown scripting to bridge the gap between git structure and CVS structure
Eliminate subsubpackages by changing organization in CVS and updating references as needed (but we still need an existing or custom homegrown tool which handles the two levels)
Git or third-party "Sub" tools
...
Both subtree and subrepo appear to handle branches reasonably well. In the more recent subtree doc the description of how to push changes to the subtree back to the remote is a bit daunting, especially since this is likely to be a common operation for developers. This was one of the motivations for subrepo subrepo doesn't have this issue, in fact fixing it was one - perhaps the chief - motivation for writing it.
I don't see any discussion of tags in the documentation of any of these tools but, since we've traditionally used home-grown tools rather than naked CVS commands for tagging already (C++ program stag for individual subpackages; tagCollector.py for release and release candidate tags), perhaps this isn't so important.
My tentative conclusion is that we can eliminate submodule and subtree from consideration; subrepo should be investigated further. In particular we should see how it does with a three-level hierarchy.
Scripting bridge
Each subpackage or subsubpackage (that is, anything with an SConscript in its top directory) goes in a separate repository, as with previous strategy, but we write our own custom tool to help with the scenarios we expect to encounter, and not much more.
...