Yesterday's screed elicited some comments from the good folks over at Cincom. Avi Bryant notes:
The thing is, when you move away from code and into arbitrary data files, most of the useful features of *any* version control system go away. [...] The most you usually need or are able to do is to associate a specific revision of a binary file with a specific version of the code[...]. Now, where there's some truth to ziggy's argument is when it comes to non-Smalltalk code that needs to be managed in a Smalltalk project; the most obvious examples for web apps are CSS and Javascript. I'd love to extend Monticello to parse CSS by selector and do the same kind of semantic merging with it that I can do with Smalltalk methods.There are two issues here. Within the context of an image, higher level semantic tracking of revisions is possible, whereas it is impossible to perform that kind of semantic tracking when dealing with data files of random content. But even within an image, it's not possible to do semantic analysis of everything that needs to be under version control. Sure, you could add parsers for CSS and JavaScript. But what about HTML tag soup? TeX and LaTeX? C/C++ code? Makefiles? Where does it all end?
Versioning changes within the context of a live image is a really cool hack. It does make the nastiness of darcs' Theory of Patches go away in a puff of smoke when tracking changes to objects and methods. But it does not eliminate the need for revision control of "arbitrary text files". Jumping through hoops to track changes in text files with random content may be retrograde within a Smalltalk image, but they are certainly not "unnecessary".
On this side of the Smalltalk fence, we're not that familiar with versioning parsed, live code within an image. But we're also reasonably happy with throwing any random file into a revision control system, confident that it will track changes (or copy binary files) between revisions. We may be dealing with text diffs, but the techique is remarkably scalable -- the same skills work for tracking changes to any kind of text file, whether it's tag soup, Perl, C, config files or some baroque write-only language I whipped up one night while wired on Yerba Mate. And all but the most trivial projects use a variety of different languages in some capacity or another -- C sources, Makefiles, Shell scripts, and so forth.
Elsewhere, James Robertson corrects a factual error I made in haste:
Hmm - it's not a VM level thing - the code and parse trees are all available at the Smalltalk level - which is a large part of what makes them easy to deal with.Yep. I misspoke. I said things like ...the VM can track every change... when I meant ...the Image can track every change.... Thanks for the clarification.
James goes on to say:
The point is, the various file based systems aren't perfect either, and they simply don't mesh well with image-based development.Yep. Nothing's perfect. My point was that tracking changes in text files (like CVS does) is still relevant, even within a Smalltalk image. Adding parsers for CSS and JavaScript can help, but it that ignores the underlying problem, but doesn't eliminate it. (Thus the term "Smalltalk Disease".)
Re:Version Control
ziggy on 2004-12-02T15:06:14
Yep. I'm assuming for the sake of argument that these features can be/have been built on top of Monticello and friends. If not, it should be a SMOP. Those features can be built on top of anything that can diff and patch, and maintain a database of revisions.
