Sven, I think the issue is one of mechanics
... Imagine a small system where we have 5 engineers doing 2 commits per day with an average of 4 mcz files touched per commit ... that's 40 modified mcz file per day ... 10% of the commits are aimed at a bugfix release on an earlier version of the product, 10% of the commit are aimed at adding features for the next functional release and 80% of the commits are aimed at the next incremental release ... In this scenario a Smalltalk team would struggle. I don't think the out-of-the-box toolset can handle this (for Squeak and Pharo)...It certainly can be done in Smalltalk, but I think it would require some additional tools customization/development. Your comment about git is right on: "Yes, git has a bit more tools, is a bit more modern, has a lot more usage and polish" Those things are missing from the Smalltalk toolset. The Smalltalk tool set _can_ be improved ... is being improved ... but it has fallen behind... At some level we are competing with git more than we are competing with other languages... Dale ----- Original Message ----- | From: "Sven Van Caekenberghe" <s...@beta9.be> | To: Pharo-project@lists.gforge.inria.fr | Sent: Sunday, January 29, 2012 8:02:51 AM | Subject: Re: [Pharo-project] Smalltalk for small projects only? | | | On 29 Jan 2012, at 15:30, Philippe Marschall wrote: | | >> As for scale.. monticello scales well. | > | > No, it does not. | | Please elaborate: I really can't see the difference between doing a | merge (either an easy one or a more diffucult one over multiple | files, spread over a couple of days, with intervening changes by | others) using either Monticello or Git. | | Yes, git has a bit more tools, is a bit more modern, has a lot more | usage and polish, but fundamentally I see little difference. The | merge will be hard in both cases. All (big) teams struggle here. | | BTW: try understanding git internals, let alone try contributing to | it, with Monticello you can: it is all Smalltalk. | | Again, I am not saying that MC has no flaws, or that we can't or | should learn from others and improve, far from it, but the grass in | not greener on the other side. | | Sven | | PS: one of the things that we should take from git, as many others | have said on this list, is selective commits. |
