...

There are two subpackages (irfs, celestialSources) which have subsubpackages (that is, separately taggable physical subdirectories). celestialSources belongs to both ST and GR.  SCons and Release Manager recognize subpackages and subsubpackages by the existence of a file called SConscript.  In addition to specifying to SCons how to build the package, this file also contains version information.

Handling subpackages and subsubpackages

The single fact causing us the most grief may be this: CVS tags apply to a directory (optionally recursively); git supports tags only of entire repositories.  Hence we surely need separate repositories for subpackages .  and a way to reassemble the hierarchy when they're checked out.  It's less clear what to do about subsubpackages.  There are only two subpackages with subsubpackages: celestialSources and irfs.   Our custom subpackage-tagging software goes to extra trouble to avoid tagging subsubpackages when the parent subpackage is tagged.

...

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.

Flatten hierarchy

Having a third level to our hierarchy introduces significant complication.  Since there are only two packages where this is an issue it's tempting to change the structure to make the subsubpackages full fledged subpackages. This would affect other subpackages somewhat, e.g. in #include references; we need to make a survey to find out just how much work this would entail. In the case of celestialSources, this would impact GR as well as ST and ST_U.