On 29 January 2012 16:29, Steve Wart <steve@wart.ca> wrote:
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.
(a) Count me in on a git-based backend (I use github! Without chunk format!) and (b) I know of at several git-using projects - Tim Felgentreff's Gitocello (https://github.com/timfel/gitocello) dumps chunk format into a git repo (tracked as you use Monticello) - GSOC 2010 had a proposal l(http://gsoc2010.esug.org/projects/git-mercurial) - Goran, did this get off the ground? Or is the r - Tony Garnock-Jones wrote a git repository implementation (http://www.squeaksource.com/Git.html) - Pharogenesis (https://github.com/pharogenesis/pharogenesis and http://scg.unibe.ch/research/Pharogenesis) defines what looks like a reasonable mapping, and that comes from - GitFS (http://www.squeaksource.com/GitFS.html) I suspect that most of the pieces of the puzzle are just lying around waiting for someone to plug them together! (Clearly writing TO the repository is trivial. You'd also want the reverse: "oh, the repo's updated; load the new versions of things." This is where things might get tricky, because the load order of things may be important.)
How would git work? Source code in files, how quaint, and all that?
Easy enough to address that perception though: "no, source code in an object database (for lo, that's what git is)"!
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)?
Really, I suspect it's just that no one has sufficient time/interest/energy. Well, there's definitely _interest_ :) frank
Cheers, Steve
On Sun, Jan 29, 2012 at 7:09 AM, Philippe Marschall <kustos@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