I feel like I should answer part of your question more directly than I did: "Would you serialize and dump a set of source code from an image? Would you build t

I feel like I should answer part of your question more directly than I did: "Would you serialize and dump a set of source code from an image? Would you build the reference image from a source code project and manually handle the consistency between source files and images?" Yes, this is a normal way to manage changes in Lisp projects. I should mention that, even when I'm using images as I've described, I use text files, not image files, as the canonical storage for my code. I use images in the ways I've described, but I don't use them as the main way to store the reference version of my code. Consequently, the normal way I manage Lisp projects (and the way I've seen other Lisp hackers do it) is to use git or similar tools to manage versions of the source code. I build reference images, working images, and release images from those source files. Smalltalk systems have always been more oriented toward managing everything from within the image, and the Smalltalkers I've worked with generally treated text files as a serialization format for exchanging code with others. The canonical form of the source code was in the image. (Well, really, it was in the sources file, but that's basically just backing store for the image.) I work with Lisp much more than with Smalltalk, so I'll defer to other commenters on the current best practices for managing Smalltalk projects with revision-control tools. I will mention that some older Lisp systems were a little more like Smalltalk systems, in that they had more tools for version management than currently-available systems. Interlisp, for example, had a pretty impressive change-management facility called Masterscope, and Lisp Machines had a versioned file system--the machine's filesystem was a revision-control system.