Hi Dale and everyone-- I think traditional Smalltalk is just file-based enough to cause major annoyance for everyone. :) This seems like yet another good moment to read Ingalls' "Design Principles Behind Smalltalk"[1]. What resonates most for me are the "messages" and "uniformity" principles. In Smalltalk's first several development cycles in the 1970s, key technologies which could enable the realization of those principles (and which have since become commonplace) were still nascent. Specifically, establishing network connections between arbitrary computers was relatively difficult, and the connections themselves were relatively slow and expensive. In that situation, it seems more attractive to use files to communicate changes, rather than using remote messaging, even though that's a retreat from uniform application of the communicating-objects idea. Perhaps remote messaging wasn't even considered then (hm, if only there were people from that time who could tell us... :). Anyway, once you've decided to use files to communicate changes, you establish several conventions which are hard to drop. These include: - It's normal to express an application as a set of differences from some known object memory state, or one that is "close enough"... except when it isn't. - It's normal to express those differences as source code, to be compiled by an object memory which is again "close enough". - Conveying changes from one Smalltalk system to another is not an interactive process. If the changes in a file are wrong, you need to fiddle with the file yourself, or change the system that made the file and recreate it. The dependency relationship between multiple files of changes is even more problematic. Change sets and fileouts are a result of these unfortunate conventions, but they need not be integral to Smalltalk. However, this is all independent of the external interfaces we can provide to an object memory. Another thing we can do with today's easy/fast/cheap network connections, and the web services that have grown around them, is provide WebDAV access to object memories. A Smalltalk WebDAV server could provide a virtual filesystem, suitable for use with anyone's Favorite Text Editor. It could present whatever file content and file/directory structure it likes (e.g., a mapping to classes and methods in some useful way, like Casey mentioned), and perform whatever side effects it likes when those virtual files are changed by the Favorite Text Editors. People would be free to copy those virtual files and put them into whatever other system they like (e.g. git), but the interesting stuff happens when the files make their way back into the virtual filesystem, through those WebDAV server side effects. I suspect one could integrate writes to the virtual filesystem with commits to another system. (Despite that, I agree with Steven that it's the "social coding" affordances of git that are really interesting, not git's mechanisms per se.) -C [1] http://tinyurl.com/3wyxavt (archive.org) -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547