A substrate for source code/project/version management
Last updated at 2:34 pm UTC on 16 January 2006
2. A substrate for source code/project/version management
This proposal intentionally avoids the details of source code management including loading and unloading, and versioning schemes. It is meant to provide a basis for such schemes.
The point of this scheme is to allow any and several schemes for handling such things as remote and net-based repositories, version management.
Each Package corresponds to a Module. This means that each package will reside in its own Module, of course. However, we also need to allow packages to modify other parts of the system–this would be considered as allowed but bad and discouraged behavior. Cf. SCANS Layers.
Each Module has an annotations dictionary; a general facility that may be used in various ways.
A module also always has a Repository object, with a standard protocol, where subclasses implement different repository schemes. The protocol would have at least name, version, and URL. The URL can code the kind of retrieval scheme to use beside location info. It would seem useful for submodules to have parent-relative URLs, to allow easy moving. Note that the URL needn't be hardcoded but may profitably be generated from name, version, etc.
It would be useful to have a standard hierarchical location scheme that matches the module structure (i.e. subdirectories<->submodules), which can be shared by local file schemes and remote storage schemes.
The in-image info for a Module–module composition (submodules + imports), Repository object, and annotations–would have a corresponding read/writeable file format. A standardized but also informative filename seems useful. Hence, not a file named "type" or "0.1", but "Module .inf" or some such. This file would also hold info about those files that should be read in to import the Module.
Note: It would be Very Useful to separate well-formed files from naughty ones that make changes outside their Module. The former can easily be undone, but the latter cannot easily be undone for the general case, esp. after other changes to the image.
