Store BOF, VW7 Cincom
Alan Knight feels the fundamental Store decision (to use an RDB) is good but the implementation reflects the problems ParcPlace was having at that time.Various issues were mentioned: reloading a bundle over a slow connection is noticeably slower than loading it the first time as it has lots of 'is this later / changed' checks. Changing packageItemCount to comment out forRequest ..., replacing it with a simple ^1 makes some loads go much faster (but you lose your progress dialogs).
The merge tool should be cleaner, e.g. merging classes where instvars have changed. John Brant had bad experiences with the merge tool initially therefore rarely uses it (the effect was to make it look as if all methods had been changed). Jim Robertson advised not marking things integration-ready unless you mean it. Invoking merge from Store reacts to that. Travis has never had a problem with the merge tool. Jim agreed that once you learn its limitations then 2 or 3 way merges are OK. Don Roberts has found that one way of invoking merge was good and another was bad. Sames said the problem was the tool's failure to present a clear model of its limitations and way of working. I agreed to check the current 'Store usage patterns' Wiki page(s), add to them as needed and prompt others to record their experience. Cincom want to use the refactoring browser's tools for store, not the old browser. Thus they are refactoring the store tools' application models to allow this. Meanwhile, there is much inconsistency in the store windows functions. (Metaclass definitions are also going away.)
Some people asked Cincom to use community Store add-ons. However, user code tweaks to Store that work in one configuration may fail or have great performance problems in others. It takes much effort to verify them on all platforms, so cannot be done outside the standard release cycles.
Travis wanted to morph user names when publishing to distant repository? It just causes confusion if his work appears in the open repository under confusing usernames. He sorts his work under project names like 'xp', 'pdp' in his local repository where everyone knows who those names signify and they have a useful sorting function. When he exports to the open repository, these names should all be mapped to tgriggs or similar.
Vassili asked whether we should have categories as a final expandible level within packages. Most people were against or indifferent, very few in favour. Some proposed dropping categories, either entirely or converting them into searchable keywords.
The replicator can be used to move bundles with version information between databases without having to go through the image. John Brant pointed out that it's more performant to replicate from the far-away machine to the near one than the reverse, as the process is chattier to the replication source than to the destination.
Travis pointed out Diana Merry-Shapiro's useful utility (Method History, in the open repository) that assimilates Store and change lists to show all method versions you wrote in the current image and all in store in single list, giving an effect similar to what Envy did. It also has useful comparison features and is a good place from which to launch merges. (John Brant: FYI non-appearance of this utility's arrow widget on Linux is Linux bug.)
Travis also recommends the TOI configurations' package ('Store Extensions' would be a better name for it) for lineups: it uses the prereqs of a no-content package to capture lineups. By contrast, Bruce Badger and I think lineups should be bundles for reasons to do with test repeatability. I want to be able to load the exact set of packages on which I ran the tests and then versioned last week, or last year. Only a line-up that captured those exact versions, not merely the bundle and package names, would be acceptable. I am also conscious that the current tools are set up to display and load bundle contents well and prereq chains much less well. If pre-req line-ups are to become practical politics, they must be integrated with the UI tools; might it be better to address the reasons why bundles currently do not make ideal line-ups (and meanwhile maybe accept their imperfections instead of those of prereqs)? Bruce and I also felt that if a no-content prereq line-up was to be created, it should be a helpfully-named bundle (which people expect to be a line-up and to have no direct content), not a package.
Several people proposed giving Store an object model mapped to the RDB by an O/R mapping tool (a Store for GLORP package is in repository). This would let Store run as a server (and/or on GemStone), so deal with high-latency links, etc. (N.B. the issue is latency, not bandwidth. Store is less chatty than Envy but when link latency reaches 300ms, Store operations become unhappy.) Also you could put policies on the server instead of having to distribute a policied image, have the server run relevant SUnit tests, etc. You could also have the RDB only on the server, not the client. (Desire to BOSS out properties, etc., to swap between images.)
John Brant, I and others mentioned the need for useful blessing comments, which few provide, the difficulty of reaching the package comment when browsing unloaded items (can find it but it is slow) and the general problems which these facts create for people trying to find things in the open repository that might help them. I rely on the user name and my knowledge (from my conference reports, etc.) of what people's interests are to deduce the likely intent of most open repository pundles. Without some years' experience of the Smalltalk community, I would be lost.
Documentation: VW documentation is noticeably improving as releases go by. Store for Envy users (Alan's talk) is on StS2002 CD (get the CD from STIC; free to members).
Store is better than Envy. It is much better at remote working (Sames keeps Pollock in synch in three repositories, which would be harder in Envy). It is much better at package refactoring than Envy. The Store diff tool is similar to the Envy diff tool (noting that its menu layout is annoying). Its merge tool is better (not that that's saying much).
It would be nice to have an easy install script for Store, so that people doing local work or evaluations could just get started without having to wrestle with PostGres installation or suchlike. Several people pointed out that Store for Access is extremely quick and trouble free; several others remarked that they had not known that. It was agreed that a Store for Access quick-start script for single users on Windows (made very visible in documentation and/or start image) would be a sensible addition.
A read-only connect to the open-repository could also be provided easily, linked to some kind of registration, perhaps, but very easy for the interested user to set up. (However John and my earlier comments about needing a good understanding of the Smalltalk world to find things in the current repository are relevant to assessing the value of doing this. Maybe we need to discourage uncommitted users until this is fixed.)
Q. Can we explicitly delete bundles? There is a method that does this which is nowhere exposed; you must invoke it programmatically.
Q. VW7.2 will have a runtime image. Can Store be headlessly-scriptable (no popup dialogs)? The value was noted.
Previous Topic
