> Presumably because it predates git :) But I think 2003 is the actual birth > year.
yet it shares almost the same model as git does. Sadly the tools don't make proper use of it :). But that means that Monticello as a model isn't that bad. > But the counter argument is trivial: how many people use Monticello? > (At most, hundreds. In comparison to at least 10s of thousands using > git.) Does Monticello actually use any of the special syntax-awareness > it's supposed to bring to the table? (No.) indeed, that is one of the arguments that make git support for smalltalk absolutely feasible. And even if there is going to be special object support, I think we can store that in separate binary blobs if necessary. > But the counter-counter argument is "it's good enough". (I disagree, > but I accept the argument that it does work well enough to actually > get stuff done, even if code review in Smalltalk is currently way > harder than in Ruby or Clojure, the other languages in which I most > commonly program. And they're so easy to code review because being > git-friendly allows me to see diffs and discuss diffs and use all > manner of cool tools that hook into git.) I would love to run different branches on that topic: - in image tools (such as torch) - versioning model (such as git) those two are basically orthogonal, but if you have a look at torch you see that there is already quite a complex and rich tool available for Pharo. It needs polishing I guess and depends on too many external packages, but it is there and can server as a very good basis to go further. For the versioning model we're running multiple branches as well: - git (slow progress) - libgit bindings - filetree as a dialect agnostic fileout format (mostly completed)
