You often will not be, explicitly by contract. Honestly in this case it’s easier to keep things clean.

Can't say what and Interlisp did, but the MIT Lisp Machine and here the commercial variant Genera.

Files are versioned. The Lisp machine file system has versions (same for DEC VMS and a few other file systems). Nowadays the file version is attached to the name&type. Thus editing a file and saving it creates a new file with the same name&type and an updated version number. I can edit/load/compile/open/... files by specifying its version number. If there is no version number specified, the newest file version is used.

A site shared a namespace server with system registry and several file servers.

Code, documentation, etc. is defined as a system, similar to what ASDF does. A system has major and minor version numbers and other attributes (like being experimental or being released). Each time one does a full compile on a system, its major version gets updated and it tracks which file versions it used for that compilation. Whenever one creates a patch (a change of the sources) to a system, the minor version gets updated. After 12 full compiles and 30 patches to the latest version we have system FOOBAR 12.30. This data is recorded in the system directory, thus outside of an image (called a World in Genera) in the file system.

Now I can use that system FOOBAR in another Lisp and "Load System FOOBAR :version Newest" -> This will load system FOOBAR 12.30 into its runtime. Then new patches may appear in the system. I can then in a Lisp say "Load Patches FOOBAR" and it will look into the system directory for new patches to the current loaded major version and load those patches one by one. This changes the running Lisp. It then knows that it has loaded, say, FOOBAR 12.45, what files it has loaded and in which files the respective code (functions, ...) are located.

If I want to ship a system to the customer or someone else, I might tag it as released and create a distribution (with sources, documentation or not). The distribution is a file (also possibly a tape, a bunch of floppy disks, a CDROM, or similar). A distribution can contain one or more systems and its files (in several versions). On another Lisp I can later restore the distribution or parts of it. The restored systems then can be loaded for a specific version. For example I can load a released system version and then load patches for it.

A saved image knows which versions of what systems it includes. It also knows which functions sources are where. It may also have corresponding documentation versions loaded.

Later a source versioning system (called VC) was added, but I haven't used that.

I worked on a system implemented in Smalltalk for a few years, and the truly integrated development process possible in a ST is a high I've been chasing ever since. And this was in a setting that had so many things going against it: I started working on it in 2016, and the last update of the runtime environment was from '99. We had a custom HTTP client, and home-brew bindings to OpenSSL that I cooked up with some mad science Python that parsed C headers to generate Smalltalk code. I even had to fix a bug where Winsock fds rolled over if you opened more than 8k sockets, because the runtime FFI bindings assumed a 16 bit wide return value (I assume the code dates back to the Win 3.11 days).

By all rights, it should have been _awful_. But in reality we were able to iterate quickly and actually make stuff, because the technical foundations of the system were rock solid, the team was good, and because the truly integrated Smalltalk development enviroment enables a super-tight development cycle. A joke I have with a former colleague from those days is how all modern languages are still fundamentally no different from the punch card days: You take your sources off to the batch processing center, and the results come out at the other end, while Smalltalk is future techonology from the 80s.