Version control is becoming a hot topic, it seems: there's been an explosion of alternativeversioncontrolsystems, and a lot of associateddiscussion in the blog world. Reading about and experimenting with these systems has made me realize how relatively easy we have it in the Smalltalk world - for example, Martin Pool writes:
There are two basic complex merge problems: cherry-picking changes, and history-sensitive merging within an arbitrary graph. I don't think any single existing system (open or closed) can do both correctly, but I think it is possible.
As it happens, Monticello does do both of those correctly, but not because we're better hackers or have more time than the arch or darcs guys; I rather suspect the opposite is true. It's just that working within the restricted domain of Smalltalk code makes all the problems so much easier, because we have so much richer a model of what source code is: everyone else is held back by having to solve every problem in the general case of an arbitrary text file. The hoops this makes you jump through - like the impressive but, in the Smalltalk case, wholly unnecessary Theory of Patches developed for darcs - can be quite astonishing. Unfortunately, the other thing I've come to realize is that Monticello suffers somewhat from the same disease: Monticello's cherry-picking support, for example, is a very neat technical solution, but its complexity is a strong indication that there's something inherently wrong with the model.
The answer, as I see it, is to even more firmly embrace the advantages we have in Smalltalk, like the ability to individually address versions of single methods. This is something that ENVY got right, though ENVY fails utterly when it comes to supporting merging. But I think there's a sweet spot when you combine ENVY-like granularity with Monticello-like distributed ancestry trees, and Colin and I have started playing with some spike code around that idea. More on this as we explore it further.
Previous Topic
