Extract and edit from joevansteen on GitHub
I’m a “retired” systems architect, a programmer, a modeler, and a futurist. I am a “self-employed” professional developer.
I’ve used a variety of mechanisms as code repositories over time. In the 1970’s I had a steel case desk of the 1950’s modern design type, before things went to strict rectangles in office furniture. We (the old CA Bank of America) used to use a mix of wooden desks, and steel case “rounded design” desks for routine workers. Production programs were maintained on production Symtapes (symbolic source code maintained on a magnetic tape file and kept in a vault when not in use). Active program card decks tended to get maintained in indexed card file sets and kept in old keypunch card boxes. A big program, during active development could be a couple boxes of cards. Card boxes were kept in your desk. Merging cards onto symtapes was ideal, to get rid of the cards. But the tape had to get checked out of the vault to run the job, which was a special class job, beyond the normal jobs which only required disk packs. But if you had too many inserts in one spot, you had to renumber, and if you were working on more than one thing at a time, all renumbering had to be synchronized.
When I started on PC development I used ARC. I used to code on an 8080, then an 8086, and it kept up with me when I typed. Now I’m coding on a quad core Pentium, and I have to stop to let the editor catch up with me as I type these words. What’s wrong with this state of affairs? I moved to PK-ARC when the ARC people got strange about open code conventions. Patents on ideas make no sense either. How does it encourage free enterprise by constraining innovation and initiative? But that’s off subject here.
I got used to Visual Studio, and used it for maintaining libraries for TSM, but the best source code management system was the one developed by Irving Chew for the BAU/Teller team where we maintained multiple versions, of multiple applications, by a network of teams, and coordinated distributed front-end development with mainframe development into synchronized packages for the retail delivery systems area.
Irving’s system was written for DOS 3, and operated on an IBM Token Ring LAN.
GitHub is pretty much the bible in open source, shared development. The Architected Futures GitHub repositories provide the mechanism for synchronization of Architected Futures internal development, and any external software projects which may be related to Architected Futures activities. External project may be of concern from two viewpoints:
- Code which we depend on. (Dependency analysis goes well beyond code composition. There are also run time, and other utilization impacts to be considered in the architecture of a whole system.)
- Code which may depend on us. Anyone who becomes a user of our code, will inherit some dependency on the code, and the methods by which it came together. The purpose of code is to be used. So this can become the more important aspect.
In each case there are additional sets of factors in how the repositories are used:
- Code we developed, code we didn’t.
- Code that is tracked for application concepts, code that is tracked for technical concepts