Big legacy projects are still using Envy for VisualWorks less for the reasons listed below, but mostly because it's extremely difficult to migrate to Store without doing a "big bang" and most of these projects don't have 200+ developers anymore anyhow (disclaimer: I'm only familiar with 2 or 3 of these "success stories"). Many of the big Smalltalk projects were mostly done using Envy, and it's a powerful tool, in spite of its limitations. If there was a reliable way to move the latest changes from a set of Envy configuration maps into Store, it would make it much easier to get away from ancient, buggy and unsupported SCMs (like Envy/GemKit).
But I confess I am not a big fan of Store. It works and has some good features, but it's VW-only and the model is not acceptable for modern development practices, never mind security issues and whatnot. I would like to know better what Ralph was talking about in this interview. It's hard to generalize about this sort of thing without starting a huge rambling flame war or similarly unenlightening cascade of posts. I would personally like to see a git backend for Smalltalk that works across all dialects. VisualWorks really threw a monkey wrench into things by adding proprietary extensions but as we've seen with Seaside, if there's a common need, the community can rally together and come up with some reliably mechanisms to support all versions of the language. How would git work? Source code in files, how quaint, and all that? I don't think it's that hard. In Smalltalk a compilation unit is a method, so you store one file per method. Get rid of the changes file. Index things so everything doesn't grind to a halt. Maybe I'm missing something, but I think this is the way to go. Are there any fundamental problems with this approach (other than resources and funding and the usual perfectly valid excuses)? Cheers, Steve On Sun, Jan 29, 2012 at 7:09 AM, Philippe Marschall <kus...@gmx.net> wrote: > On 28.01.2012 21:16, Janko Mivšek wrote: > >> Dale, >> >> I agree with you that source code management is where we are weak. A >> process therefore, as James already said. >> >> In SCM VisualWorks is ahead in my opinion, even that Store is also not >> perfect yet. But it would be useful to reuse some of ideas in Monticello >> based SCM tools too. With Metacello we got a good packaging tool, so, >> where to go to be even better? I think SCM tool integration into code >> browser can be next and relatively easy step. As Store is integrated >> into VW code browser. >> > > Wow, Store. Did you know that Store is so bad that some of the biggest > Cincom success stories paid a really huge, undisclosed sum so that they > don't have to use it? > > If something cries 1995 then it's handing a SQL connection to the client. > Your "interface" is the database schema. It ties the database schema to the > client. You change the schema and you have to update all of the clients > unless you "fake" the old schema with updatable views (if your RDBMS even > supports this) and give the changed tables new names. > > Also security becomes more or less impossible to do. Once you have write > access to the public Store repository you can more or less do anything you > want to do on any project unless implement it using triggers. And then > there are all the possible DoS attacks like SELECT FOR UPDATE. > > Cheers > Philippe > > >
