Up now: The team programming panel. Eric Clayberg moderating, with Colin Putney, Niall Ross, and Bob Westergaard on the panel. The systems being discussed will be ENVY, Store, and Monticello. Each panelist has about 10 minutes to talk, followed by discussion. A few questions from Eric - one interesting thing is that most of the people in the room are working on teams of 10-20, a few bigger, a few smaller.
First up: Niall on ENVY. His first reaction to ENVY would have been better had he started with VA Assist. Assumption (correct, as it happens) - we all know what it is, how it works (etc). Small footprint, fairly easy to set up. At some level, you ran into the same divide you do with the VM/VI - you hit the C layer and can do nothing - and since the DB is proprietary, you can't get at it. Doesn't think that the version artifacts and system was immediately obvious. On the other hand, Store could benefit from having a config map equivalent. The base UI for configuration maps - appallling - especially in VW 5i.
The component ownership model - probably seemed like a good idea at the time. The existence of tools (like one Eric demonstrated) where you can become other users) is so common as to illustrate a problem inherent in the model. It tries to enforce a model of work (whereby the owner actually integrates) is one he's never seen in the field. Everyone always hacks ENVY to allow users to become anyone.
He likes the ability to export DAT files and have them remember where they came from and what they are [ed] - but.... if I publish a parcel with DB info kept, it does do that. At least mostly).
The raw toolset is very bad at tracking records. The future? Still thinks some people would like ENVY for VW. Apparently (pace James Foster), Dolphin has an ENVY-like third party tool.
Problems: Not good for remote work (chatty protocol). Always connected model is both good and bad. refactoring can be more painful given the ownership model, and the tools show their age (base tools). Lack of a merge tool, and the public/private divide is odd.
Next: Colin Putney, talking about Monticello. For some details, see the previous post. Monticello came out of a Seaside project with Avi, where they desperately needed tools (there weren't any for Squeak then).
With a versioning tool, you are trying to capture two things: Where you are now, and how you got there. Many tools impose a mode of work, and (for instance), ENVY's model wasn't appropriate for the Squeak community. In that world, you can't rely on any particular model, you have to take what you get and be grateful for it :)
Monticello is above all a merging tool, which reflects the usage model outlined above. At this point, most Squeakers use it, and the 3.9 distribution will be developed with it. The further development is really oriented towards not imposing a process model.
Next up: Bob Westergaard, on Store. There's a fair bit of history here - it goes back to Bernstein, an Eagle project "back in the day". The basic artifact is the package, with Bundles above that, where bundles can contain one or more packages or other bundles. The back end is an RDBMS. We support the major ones, and there are a bunch of community provided back ends.
Store has users, who map to DB users. Store is both loadable and unloadable, and you can develop disconnected. Store has a concept of Blessing Levels (names for published versions). Packages/Bundles can be stored binary (see the previous post again).
The user model is integrated into the existing browser via menu picks, etc. The old (pre RB) browsers are still around for when you browse the DB - that's an artifact of ongoing work which will repair that. Store really lacks a configuration map equivalent, and that's a real problem. We are aware of that, and we know that customers are rolling their own solutions. Another problem - a blown load can take out an image, forcing a restart. That should be fixed in 7.4 via shadow (sandbox) compilation.
Questions:
Envy for VW 7.x?
Niall: It's a political/legal problem, not a technical one.
About Store - overrides are great. When you have multiple overrides in an image, which one reverts?
Bob: With parcels, they restored in order, but that's broken right now. It will be fixed for 7.4.
What about class versions in Store? We want that, not just package level
Store's model really doesn't support that, it's just different than ENVY
Eliot: That was a design decision
What commonalities are there between the various Smalltalk systems in this area? They all realize that method level tracking is important, and they all integrate into the environment. Others?
Colin: The lowest "unit of work" in the Smaltalk systems goes down to the method/class level - that's very, very different than the mainstream. The mainstream simply does not get the notion of diving down to that level instead of "the file". Integration with the system really begins at the change level.
Niall: The other thing that differs is the Smalltalk notion that everything is open (not true all the way down in ENVY). This means that users can write/modify tools against the system.
Harking to the keynote on modeling - on a scale of 1 to 100, how would you rate these tools as appropriately modeling workflow?
Niall: With regards to ENVY, ownership model awful, versioning too rigid (likes blessing levels). Otherwise not too bad - overall 70-75. Nothing you would scream about other than the ownership model.
Colin: The design of Monticello really followed the usage model in the Squeak community. Smalltalk is all about live objects, so versioning in and of itself introduces a divide - one which you need to be careful around. A number? 75-80. Pretty good, but room to improve
Bob: Store has some problems with respect to its model. As to a number? About 50. A fair bit of that is based on the legacy model we have (from the early 90's)
