Sorry, but I don't buy it. I call this "Smalltalk Disease" -- the arrogant tendency for Smalltalkers to dismiss a problem because they can mutate a Smalltalk image to nearly eliminate it. (And, if they haven't done it themselves, or the necessary features aren't present in your VM, then at least someone has done elsewhere, presumably in some production environment.)
OK. So you can upgrade your VM to handle versioning and merging of Smalltalk methods. Fine.
What happens when you want to version something else, like, data files, documents, or images? I guess CVS/Subversion/darcs/etc. aren't so useless after all....
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. How well does the darcs theory of patches work on images? Can CVS insert its conflict markers into a Word file? And how many times do you need to cherry pick changes from a patch someone committed to an obscure branch of that project timeline? 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, and it would be trivial to extend Monticello to do that if the need came up.
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. To really make that work, I need to write an FTP server for Squeak, to make it easier for web designers to access in-image content without having to know anything about Smalltalk; right now I use an HTTP GET/PUT solution for this, but that's less well supported by text editors.
Previous Topic
