The coarse structure of repositories and their interaction during compilation and deployment.
V4 --> deliver --> SSL --> copyto BIN-SUBDIR --> Web --> deliver --> ASP --> copyto BIN-SUBDIR --> surface Desktop --> compile --> EXE --> copyto BIN-DIR --> surface Kernel --> compile --> DLL --> copyto BIN-DIR + DEV-DIRS --> Console --> compile --> EXE --> copyto BIN-DIR --> Inter- --> compile --> DLL --> copyto BIN-DIR --> preter Joes- --> copyto --> DB --> copyto BIN-SUBDIR --> garage Banking- --> compile --> DLL+EXE --> copyto BIN-DIR --> commander Peripher --> compile --> DLL --> copyto BIN-DIR --> modules --> DEV-DIRS = V4, V4Net, Bankingcommander --> BIN-DIR = Joes Binaries Directory
We want many independend workspaces for isolated distributed developing. Independend means e.g. that in VS, the DLL references may not point to other repositories, as is often the habit. But only to the exact one directory, where the caller itself resides. Such request affords a sophisticated make process, including e.g. copying single files to specific neighbour workspaces (as far as exist).
(S.:) That approach leads to the DLL hell!
(N.:) Normally yes. But we have a consolidated project. That makes it possible. The database is frozen, we need no changes, but want only add minor fields. It remains strictly backward compatible over long times. The source code structure is not experimental, but stable. We know in great detail where we want to go. No surprises are expected. Interfaces can be defined and frozen without expecting surprises. We have very low fluctiation, all work happens inside confined modules behind static interfaces.