Hi list,
We're are also curious about Cincom's Store roadmap. e.g. they mentioned introducing "Configuration" support a long time ago but as far as I know, there isn't much progress in the area. Since playing with vw7.7 many store-extensions we are using do not work anymore. I suppose this is because Store/VW interaction is now Glorp based. This will hopefully kick-start some long planned improvements. Before we start migrating all our store extensions to be glorp aware, I would like to know more about Cincoms' store roadmap and what has changed since 7.6. This will help us make the right decisions. about "Store lineup extensions": We're especially heavy users of "Store lineup extensions" ( a package of Cees de Groot in the open cincom repositorty). This package introduces so called Configurations and Lineups and abandons the use of "Bundles" totally. Even though, with this package much store behaviour is made dependent from a package's name (e.g. "* Config"), it still is a big improvement for Store is our experience. I'm really curious how other teams (with say at least 5 programmers working on 1 product) can work efficiently with Store without this package. Besides "configurations", "overrides" are also not well supported in Store. We try not to use them as much as possible. The problem is; when you load an individual package, which has an overriden method in the image, it will override it again. greetings, Mathieu van Echtelt On Mon, Oct 5, 2009 at 9:52 AM, Dennis Schetinin <[hidden email]> wrote: > The name is very interesting, and I remember it mentioned on blogs... But no > comments for the bundles in Open Repository and many unrevealed dependecies > preventing it to be loaded in 7.6 makes it a secret weapon... > > BTW, the lack of comments in Open Repository and usually sophisticated > process of loading (a bunch of prerequisites each having a lot of versions) > still (it's for years now) prevent beginners (students for example) from > using it (Open Repository) and sequentially VisualWorks. What about putting > some order there? > > -- > Dennis Schetinin > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > -- AG5 Timorplein 37 1094 CC Amsterdam T 020 4630942 F 020 4630946 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
ON YOUR "...I'm really curious how other teams (with say at least 5 programmers working on 1 product) can work efficiently with Store without this package."
Since 7 years, we have the strategy: 0) We ensured (by simple modifications of setting blessings and pre-checking publishing) that there is for every pundle a unique integration-ready version. 1) There is one central bundle containing all subpundles of our application in ANY version (at first it was the (most recent) integration-ready version). 2) We've written a load-method, doing the following: Load the (most recent) integration-ready (= i-r) version of all subpundles of the central bundle, i.e. trace thru (contained items (=CIs) of) the central bundle and: a) if a CI is a bundle that has a more recent i-r version, than unload all no more needed subpundles and continue the process with the contained items of the more recent i-r version b) if a CI is a package load the most recent i-r version. 3) If a developer wants to publish a package s/he merges all from the i-r version and publishs as i-r (our default) 4) If s/he has to add a new bundle B into a superbundle A, he has to edit the specification of A and to publish A as i-r. Thus every developer can load the most recent sources of the whole team and can publish at every time he wants. Cause we are checking (in the moment of publishing in DB) that your package version is child of the last i-r, the problems of two parallel publisher does not occur. The last of these two publisher gets a message that there is a more recent i-r version of the parent package where from he started before merging.
|
Thanks for your detailed explanation.
I do not understand all the details of your approach, but what I do understand is that your approach is also dependent from extensions you made yourself. Which is fine but is something I would like to avoid. Especially for source code management systems, which are about sharing code between versions, projects and people. Having extension made ourselves is now one of the problems we encounter during migration to VW7.7. About the podcast James mentioned: Good to hear Cincom takes Store's progress serious and have 2 dedicated experts working on it. In the interview is also the remark: VW/Store will "for sure not" have import/export functionality with file based scm systems like subversion, cvs. The projects I worked on for the last 10 years always had other than Smalltalk technologies involved, and these are mostly managed with these file based scm systems. More cooperation would be good for Smalltalk is my opinion. I'm still curious how e.g. Cincom is able to manage all their source code, they are with many developers working on at least 3 complex products (VW, OS, WV) and (hopefully) also share code between these Smalltalk products. But it is probabely better to wait till I meet a Cincom developer, sitting behind a computer helps so much to understand/explain such a difficult thing as scm, which is partly about tools, partly about work processes (and so far, also partly about self made extensions:). greetings, Mathieu On Tue, Oct 6, 2009 at 11:21 AM, Ulli Wenk <[hidden email]> wrote: > > ON YOUR "...I'm really curious how other teams (with say at least 5 > programmers working on 1 product) can work efficiently with Store without > this package." > > Since 7 years, we have the strategy: > > 0) We ensured (by simple modifications of setting blessings and pre-checking > publishing) that there is for every pundle a unique integration-ready > version. > > 1) There is one central bundle containing all subpundles of our application > in ANY version (at first it was the (most recent) integration-ready > version). > > 2) We've written a load-method, doing the following: > > Load the (most recent) integration-ready (= i-r) version of all subpundles > of the central bundle, i.e. trace thru (contained items (=CIs) of) the > central bundle and: > > a) if a CI is a bundle that has a more recent i-r version, than unload all > no more needed subpundles and continue the process with the contained items > of the more recent i-r version > > b) if a CI is a package load the most recent i-r version. > > 3) If a developer wants to publish a package s/he merges all from the i-r > version and publishs as i-r (our default) > > 4) If s/he has to add a new bundle B into a superbundle A, he has to edit > the specification of A and to publish A as i-r. > > Thus every developer can load the most recent sources of the whole team and > can publish at every time he wants. Cause we are checking (in the moment of > publishing in DB) that your package version is child of the last i-r, the > problems of two parallel publisher does not occur. The last of these two > publisher gets a message that there is a more recent i-r version of the > parent package where from he started before merging. > > > > Mathieu van Echtelt-2 wrote: >> >> Hi list, >> >> We're are also curious about Cincom's Store roadmap. e.g. they >> mentioned introducing "Configuration" support a long time ago but as >> far as I know, there isn't much progress in the area. >> >> Since playing with vw7.7 many store-extensions we are using do not >> work anymore. I suppose this is because Store/VW interaction is now >> Glorp based. This will hopefully kick-start some long planned >> improvements. Before we start migrating all our store extensions to >> be glorp aware, I would like to know more about Cincoms' store roadmap >> and what has changed since 7.6. This will help us make the right >> decisions. >> >> about "Store lineup extensions": >> >> We're especially heavy users of "Store lineup extensions" ( a package >> of Cees de Groot in the open cincom repositorty). This package >> introduces so called Configurations and Lineups and abandons the use >> of "Bundles" totally. Even though, with this package much store >> behaviour is made dependent from a package's name (e.g. "* Config"), >> it still is a big improvement for Store is our experience. I'm really >> curious how other teams (with say at least 5 programmers working on 1 >> product) can work efficiently with Store without this package. >> >> Besides "configurations", "overrides" are also not well supported in >> Store. We try not to use them as much as possible. The problem is; >> when you load an individual package, which has an overriden method in >> the image, it will override it again. >> >> greetings, >> >> Mathieu van Echtelt >> >> >> >> On Mon, Oct 5, 2009 at 9:52 AM, Dennis Schetinin <[hidden email]> >> wrote: >>> The name is very interesting, and I remember it mentioned on blogs... But >>> no >>> comments for the bundles in Open Repository and many unrevealed >>> dependecies >>> preventing it to be loaded in 7.6 makes it a secret weapon... >>> >>> BTW, the lack of comments in Open Repository and usually sophisticated >>> process of loading (a bunch of prerequisites each having a lot of >>> versions) >>> still (it's for years now) prevent beginners (students for example) from >>> using it (Open Repository) and sequentially VisualWorks. What about >>> putting >>> some order there? >>> >>> -- >>> Dennis Schetinin >>> >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>> >>> >> >> >> >> -- >> AG5 >> Timorplein 37 >> 1094 CC >> Amsterdam >> >> T 020 4630942 >> F 020 4630946 >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> >> > > -- > View this message in context: http://www.nabble.com/-vwnc--Cincom%27s-Store-roadmap.-Re%3A--What-is-Linkuistics--tp25748114p25765375.html > Sent from the VisualWorks mailing list archive at Nabble.com. > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > -- AG5 Timorplein 37 1094 CC Amsterdam T 020 4630942 F 020 4630946 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Mathieu van Echtelt-2
We have internal designs for supporting larger-scale
organizational units, which we have internally been calling Projects, but
you are correct in that that has not moved forward recently. It's
something that I think you want to think pretty carefully about before
putting out an implementation.
There's quite a lot of work on Store in this release. In addition to the internals of most parts of it now using the StoreGlorp back-end, it also uses shadow (or atomic) loading by default. Both of these are things that have the potential to break extensions which rely on the old mechanisms. But we think that they provide quite significant benefits. With a stronger model in the back-end, it should also be fairly easy to update old extensions. The next major thing on the agenda is work on the merge and comparison tools. These are not yet Glorp-based, and there are a few other issues with the existing tools that users have mentioned over the years. In terms of more details of what has changed I'll refer you to the 7.7 release notes (once 7.7 is released, I don't think most of that information is there yet) and to the fixed_ars.txt list for an exhaustive list of ARs. I will mention that there was also a lot of work done on fixing issues with overrides, although the particular one that you mention is not yet addressed. At 05:59 AM 2009-10-05, Mathieu van Echtelt wrote: Hi list, --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |