Jan’s question points to a real (and often misunderstood) difference: classic Smalltalk development treated the **running image** as the primary artifact, whereas Unix toolchains treated the **filesystem full of text files** as the primary artifact. That difference ripples into how teams collaborate, how “a change” is represented, and what “merging” even means. Below is a structured answer you can drop into a FedWiki page or use to continue the thread. --- ## What was the “model of team interaction” in Smalltalk teams? ### 1) The image is the development substrate In most classic Smalltalk systems (e.g., Xerox PARC lineages, later VisualWorks, etc.), you work inside a live environment: * You edit methods/classes in a browser, not in files. * You compile continuously; the system updates immediately. * The “program” is the image: objects in memory plus compiled methods. So the daily workflow is: **load image → make live changes → test immediately → save image / export changes**. ### 2) Source is not “the project directory” The exchange you quoted summarizes the key internal mechanism accurately: * The image contains **compiled bytecode** (CompiledMethods). * The corresponding **source text** is typically kept in a **separate source repository file** (often a random-access file), with each CompiledMethod holding *pointers/metadata* to where its source lives (plus timestamp/category/protocol, etc.). * Every successful compile updates those pointers and the source store. This is a different ontology than “source files in a repo.” It is “source as metadata-attached method definitions indexed by the system.” ### 3) Changes are recorded as a first-class stream: ChangeSets Smalltalk environments typically maintain: * a **ChangeSet** (or multiple) recording each accepted change (method add/replace, class definition change, etc.) * often also a **changes log** file A ChangeSet is less “diff between files” and more “ordered log of semantic operations”: * “compile method X in class Y” * “add instance variable” * “rename class” * etc. That is why people say it’s “always accurate”: it is created by the IDE at the moment the change is made, not reconstructed later by comparing files. (A Unix `diff` is a *derived* artifact; a ChangeSet is *primary*.) ### 4) Collaboration pattern: exchange and integrate change logs, not file patches Before modern VCS was widespread (and before VCS was common on Unix, per the quote), a typical team pattern was: * Each developer works in their own image. * They periodically **file out** a ChangeSet (or a “chunk” file) and share it. * Teammates **file in** those changes into their own images. * Conflicts are resolved at the level of methods/classes when filing-in, often interactively, but without a “three-way merge” model that assumes a shared base revision of text files. This is exactly analogous to “mailing patches,” but the patch payload is **semantic Smalltalk definitions** rather than line-oriented edits. ### 5) The mismatch with Unix source control is about *granularity and merge semantics* Unix-centric source control (historically SCCS/RCS, then CVS, then SVN, then Git) assumes: * the project is a set of text files * changes are line-based edits * merges are text merges on files Smalltalk classic practice assumes: * the project is an evolving object system in an image * changes are method/class operations * the “unit of merge” is a method/class definition (or package), not a line range inside a file You can bridge these worlds, but the “default mental model” differs. ### 6) When teams scaled: Smalltalk did develop native “source control,” but it wasn’t Unix-like As soon as teams got larger, informal “file-out/file-in” becomes insufficient (history, branching, controlled integration, reproducible builds). The Smalltalk world responded with tools that match the image model, for example: * **ENVY/Developer** (notably in IBM Smalltalk) and similar systems: versioned *applications/packages* with explicit editions, prerequisites, and a shared repository. * Later package systems (parcels, bundles, Monticello/Squeak, etc.) that treat packages as the unit of versioning. These tools make collaboration robust, but they still do not reduce the world to “merge text files in directories.” They version *packages and method definitions*, often with metadata richer than a file diff. --- ## A crisp answer to Jan’s “What was the model?” If you want a one-paragraph reply in the thread, something like this is faithful: > Classic Smalltalk team collaboration was image-centered: developers worked live in their own images, and the system recorded changes as ChangeSets (a semantic log of method/class operations). Sharing work meant filing-out and filing-in ChangeSets or packages, rather than committing line-edited text files. Unix source control assumed the filesystem of text files is primary and merges are line-based; Smalltalk assumed the running system is primary and merges happen at method/package granularity, often via tools like ChangeSets and later repository systems (e.g., ENVY). --- ## Where the original claim (“fundamentally different from Unix source control”) is fair—and where it’s overstated **Fair:** * The *primary artifact* differs (image vs filesystem). * The *unit of change* differs (method/class ops vs line diffs). * The *default merge story* differs (semantic import vs text merge). **Overstated:** * In practice, Smalltalk teams did patch exchange just like Unix teams (mailing changes), and later built proper repository tooling. So it’s not “couldn’t collaborate,” it’s “collaboration tools were shaped by the image model, not by the Unix file model.”
pages/model-of-team-interaction
