Hello

stregone at att.net wrote:

> I'm the Chief Architect/CTO for a software company and as I mentioned in an 
> earlier post, we're starting several new projects.  Some of these projects are 
> using Smalltalk (the first time for us, though I've been using it at home for 
> years).  The reasons for switching to Smalltalk are various but mainly revolve 
> around faster implementation, existing projects/libraries that implement some 
> of the functionality we need, and the fact that I tired of our constantly 
> breaking procedural Java code.

Great to read this; these kinds of words probably reinforce the 
motivation of many Squeakers .... ;-)


> The "problem" is this.  Up until now we've used CVS for code versioning, 
> sharing, and back-ups.  CVS works at the "project and class" levels.  Now, 
> I've looked around a bit at the options available, but unfortunately I won't 
> have time to try them all- so I'm hoping to benefit from the experts on this 
> list.

> First off, do we have a best pratices page for team development on the wiki?  
Not yet! Actually team development is something we are struggeling with 
constantly and haven't found an excellent solution yet. But that's 
probably inherent in OO development generally if one is striving for 
optimal solutions.
In commercial Smalltalks the ENVY versioning system is good; you can be 
incredibly fast if you use the concepts which are at hand (good but not 
generally known in the versioning system world) and don't try to do what 
is not possible.


> We it be of use to anyone if I documented this changeover that we're making as 
> a commercial software house?

Of course not, go ahead please? This kind of real life reports are very 
valuable as the will show the real problems ...

There are many experts on this list who will help you ...

> Secondly, it seems to me that perhaps Monticello is the closest thing to CVS 
> in the sense that it also operates on the package and class levels?  
Yes. But other people are more competent than I to answer this.



Frankly speaking I think you show courage going for Smalltalk with a 
team, but depending on the applicatin domain or the context of your 
development cycles Smalltalk is a real option.



Hannes