Using VW 7.6, Store database is running on Microsoft SQL Server. We have found, for the second time in a month, a method in our image that does not match any of the versions of that method in Store. For example, in ClassA, in the image we see the method like: foo self bar ifTrue: [^self baz]. But in Store, all three versions look like: foo ^false. We are trying figure out 2 things 1. Where does the first, non-Store version come from? It happens if I take a plain VW 7.6 image and load our bundle from Store. 2. Which methods in our image do not match Store? As I begin my crash course in Store, does anyone have some helpful suggestions as to breakpoints I might place to discover 1, or code I might run to determine 2? All help and shortcuts appreciated, thanks, Steve Cline _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Steve Cline
|
Dear Steve,
re-reconciling should let you answer 2. For 1: - I presume you would have said if the method were an override. - I presume the method is in a subpackage of your bundle - not in the vanilla image you start from nor in a parcel loaded as prereq of your bundle or one of its subpackages. (From your description, the package containing the method should not also be loaded as a parcel.) - Is the method an extension of a class in the base image or is the class also loaded in the bundle - A postLoad property of a loaded pundle, or a class-side initialize method of a loaded class, could be redefining the method. PostLoads are best checked by eye to see if any are set. A class-side initialize method would almost certainly refer to the method selector, as symbol or as string. If these suggestions do not help, maybe send screenshots. Yours faithfully Niall Ross >Using VW 7.6, Store database is running on Microsoft SQL Server. We have found, for the second time in a month, a method in our image that does not match any of the versions of that method in Store. For example, in ClassA, in the image we see the method like: > >foo > self bar ifTrue: [^self baz]. > >But in Store, all three versions look like: > >foo > ^false. > > >We are trying figure out 2 things > > >1. Where does the first, non-Store version come from? It happens if I take a plain VW 7.6 image and load our bundle from Store. > >2. Which methods in our image do not match Store? > >As I begin my crash course in Store, does anyone have some helpful suggestions as to breakpoints I might place to discover 1, or code I might run to determine 2? > >All help and shortcuts appreciated, thanks, Steve Cline > > > >------------------------------------------------------------------------ > >_______________________________________________ >vwnc mailing list >[hidden email] >http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Trying to "re-reconcile" as suggested - I come from an Envy background, so many of the terms and operations new to me
Starting at the launcher, i click on Browse/System to open a Packages browser I select the package, class, and method in question Right click on the Package - select Store/Reconcile with database Get dialog: "Package already has a parent. Select new parent?" If I say no, nothing seems to happen. If I say yes, I get a list of all versions of the package. I pick the most recent, not being sure of what is wanted. I get a dialog with progress bar "Comparing versions of package Foo". It completes with no obvious output, in the transcript or elsewhere. What am I missing/not understanding/doing wrong? Thanks again, Steve Cline
Steve Cline
|
You're doing it right. It's enough just to select the package, that will
reconcile all its contents. Unlike Envy, where each time you edit a method it creates a new edition of that method in the Envy repository, in Store there are no separate, automatically created editions of methods or classes. Store only contains versions of packages, which get written to the Store repository only when you explicitly publish. What reconcile does is compare the contents of the package in the image with the contents of the selected version of the package in the Store repository. After you have reconciled, you can see any differences from the package icon (it shows a red plus and the number of changed methods in orange after the name). If you reconcile with the current version, then in theory it shouldn't do anything, because VisualWorks already knew all the changes that you had made in the image after the last publish: the package icon already showed them. In some more complicated cases VisualWorks can get confused, and then reconcile will help get things back in synch. So, presumably before reconcile your package was showing no changes: does it now show it has changes? HTH, Steve > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of swcwork > Sent: 2. syyskuuta 2011 0:01 > To: [hidden email] > Subject: Re: [vwnc] VW 7.6 - method in image not in Store - how did it > getthere? > > Trying to "re-reconcile" as suggested - I come from an Envy background, > so > many of the terms and operations new to me > > Starting at the launcher, i click on Browse/System to open a Packages > browser > > I select the package, class, and method in question > > Right click on the Package - select Store/Reconcile with database > > Get dialog: "Package already has a parent. Select new parent?" > > If I say no, nothing seems to happen. > > If I say yes, I get a list of all versions of the package. I pick the > most > recent, not being sure of what is wanted. > > I get a dialog with progress bar "Comparing versions of package Foo". > > > It completes with no obvious output, in the transcript or elsewhere. > > What am I missing/not understanding/doing wrong? > > Thanks again, Steve Cline > > -- > View this message in context: http://forum.world.st/VW-7-6-method-in- > image-not-in-Store-how-did-it-get-there-tp3784143p3784764.html > Sent from the VisualWorks mailing list archive at Nabble.com. > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by swcwork
Steve, No, you should not automatically reconcile to the most recent version - only if you intend to. Rather, you should typically reconcile to the version you have loaded. If that happens to be the most recent version, great. Each package loaded into the image remembers the version from which it was loaded. The image also maintains a changeset for each loaded package. When a package is loaded from store, the changeset is clean/empty, because there are no differences from the loaded version. If you add/change/delete a method from the changeset, the changeset will hold one item (the addition/change/deletion). More changes add more items to the changeset. Reconciling does 2 things: 1) The changeset for the package in the image is discarded and replaced by a new one describing the differences between the package in the image and the version in the repository against which you reconciled. If the package in the image is unchanged from the repository version you selected, the new changeset will be empty. As an example, change a method in the image, then change it back again. The package will show dirty. Re-reconcile to the same version in the repository, and the package will show clean, because the method has the same source. 2) The package in the image will think it was originally loaded from whatever version you reconciled against. So if you loaded version 1.0, but reconciled against version 1.7, the package in your image will think it was loaded from 1.7. If the image package was unchanged from version 1.0, the changeset will describe the actions that would have been needed to load version 1.7 and then modify it until it looked exactly like version 1.0. The implications involve parenting in the repository. Every version in the repository remembers its parent version. If I load 1.7 then reconcile against 1.5, the next time I publish it will suggest 1.5.1 (assuming 1.6 already exists). There can be times when one intentionally reconciles to a version other than the one that was loaded. But it's not typical, and not for the Store newbie. [hidden email] From: swcwork <[hidden email]> To: [hidden email] Sent: Thu, September 1, 2011 4:01:26 PM Subject: Re: [vwnc] VW 7.6 - method in image not in Store - how did it get there? Trying to "re-reconcile" as suggested - I come from an Envy background, so many of the terms and operations new to me Starting at the launcher, i click on Browse/System to open a Packages browser I select the package, class, and method in question Right click on the Package - select Store/Reconcile with database Get dialog: "Package already has a parent. Select new parent?" If I say no, nothing seems to happen. If I say yes, I get a list of all versions of the package. I pick the most recent, not being sure of what is wanted. I get a dialog with progress bar "Comparing versions of package Foo". It completes with no obvious output, in the transcript or elsewhere. What am I missing/not understanding/doing wrong? Thanks again, Steve Cline -- View this message in context: http://forum.world.st/VW-7-6-method-in-image-not-in-Store-how-did-it-get-there-tp3784143p3784764.html Sent from the VisualWorks mailing list archive at Nabble.com. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Steven Kelly
I do now see that the package icon shows as dirty after the reconcile - and I did want to reconcile agentst the latest version, as that reflects what is actually running on our servers. Based on my need to explain/resolve 1 (image contents do not match Store after fresh load) I then publish, and now Store should contain what is in the image. Re-reconciling on the latest version (what I just published) now shows no differences, which is what I want.
I am still puzzled by how 1 came to be - how can the contents of the image not match what is in Store? I would like to discover where the non-Store code is coming from, and several possibilities / techniques were mentioned, but they are operations that are new to me (not conceptually, I recognize some with Envy equivalents) but I need to find the appropriate intercept points. Thanks again, Steve
Steve Cline
|
Steve
Usually, you only want to reconcile against your current version, not necessarily the latest. If you reconcile against the latest and then publish you run the risk of losing changes in the latest version. The correct process is to make changes to your version and then publish it. If it is not the latest version, the new version number should reflect a branch version. Next, you merge it with the latest trunk version. The proper way to merge, is it to load the latest trunk version and then merge your branch into it. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of swcwork > Sent: Friday, September 02, 2011 9:18 AM > To: [hidden email] > Subject: Re: [vwnc] VW 7.6 - method in image not in Store - how did it getthere? > > I do now see that the package icon shows as dirty after the reconcile - and I > did want to reconcile agentst the latest version, as that reflects what is > actually running on our servers. Based on my need to explain/resolve 1 > (image contents do not match Store after fresh load) I then publish, and now > Store should contain what is in the image. Re-reconciling on the latest > version (what I just published) now shows no differences, which is what I > want. > > I am still puzzled by how 1 came to be - how can the contents of the image > not match what is in Store? I would like to discover where the non-Store > code is coming from, and several possibilities / techniques were mentioned, > but they are operations that are new to me (not conceptually, I recognize > some with Envy equivalents) but I need to find the appropriate intercept > points. > > Thanks again, Steve > > > -- > View this message in context: http://forum.world.st/VW-7-6-method-in-image-not-in-Store-how-did-it- > get-there-tp3784143p3786043.html > Sent from the VisualWorks mailing list archive at Nabble.com. > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Or, another possible workflow, if you're used to other version control systems like Subversion:
Assume you started with v115 of a package. Â While making your changes, your co-workers have published 116 and 117. Â When you're done with your changes, you can:
1. Merge 117 into your image (resolving any conflicts) 2. Reconcile with 117, which parents you off of that version 3. Publish 118 This workflow is essentially the same as doing svn update before you commit.
Some people don't like this workflow, because there isn't a published version that contains only your changes and nothing else. Â That doesn't bother me, because I'm used to the Subversion way of doing things from before.
Randy
On Fri, Sep 2, 2011 at 6:31 AM, Terry Raymond <[hidden email]> wrote: Steve Randy Coulman [hidden email] _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Thanks Randy & Terry, but the thing I am baffled by is that the version of the method in my image is not in Store at all. I have loaded our very first bundle published on 7.6 into a fresh 7.6 image, and the method in my image matches the current production image, but none of the 3 versions in store match the current implementation that I see. One of the old-timers on this project speculates that it might come from migrating from an earlier version of VW and migrating repositories, or that my versions browser is not seeing all the versions actually in Store.
Wondering, Steve
Steve Cline
|
A couple of other options:
* Perhaps the method in question is being loaded as an override from another package or bundle. Â If so, it should show up in red (if I remember 7.6 correctly). * Perhaps some piece of code, or a postLoad action is dynamically compiling a new version of the method. Â That would be evil, but possible. Randy
On Fri, Sep 2, 2011 at 1:10 PM, swcwork <[hidden email]> wrote: Thanks Randy & Terry, but the thing I am baffled by is that the version of Randy Coulman [hidden email] _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by swcwork
Do you have mechanisms which automatically generates code while/after loading?
I remember a project where certain classes/subclasses enforced creation of methods right after compiling the class or important methods... I know the question sounds dumb, but if you say that you fill a fresh image and Store has no method version matching the one in your image after finished loading, then something else has created the method. It may well be that participating packages look clean although auto-generated methods have spoiled that state, but that's the nature of loading: Having successfully loaded, Store can assume clean state. my 2 cents, Holger Am 02.09.2011 22:10, schrieb swcwork: > Thanks Randy& Terry, but the thing I am baffled by is that the version of > the method in my image is not in Store at all. I have loaded our very first > bundle published on 7.6 into a fresh 7.6 image, and the method in my image > matches the current production image, but none of the 3 versions in store > match the current implementation that I see. One of the old-timers on this > project speculates that it might come from migrating from an earlier version > of VW and migrating repositories, or that my versions browser is not seeing > all the versions actually in Store. > > Wondering, Steve > > -- > View this message in context: http://forum.world.st/VW-7-6-method-in-image-not-in-Store-how-did-it-get-there-tp3784143p3786943.html > Sent from the VisualWorks mailing list archive at Nabble.com. > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > Holger Guhl -- Senior Consultant * Certified Scrum Master * [hidden email] Tel: +49 231 9 75 99 21 * Fax: +49 231 9 75 99 20 Georg Heeg eK Dortmund Handelsregister: Amtsgericht Dortmund A 12812 _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by swcwork
How do you know for sure what's in your bundle? Until we discovered that multiple copies of the same method were contained in a version of a package in Store, we were very confused as to why we published a new version, but the next time the package was loaded into a new image, the wrong version of the method was back. We had to: - delete the method - publish - load the package into a new image (I can't recall if merely reconciling at this point was sufficient) - repeat until all versions of the method were really gone - compile the correct version of the method - publish Browsing a loaded pundle doesn't show you what's in the store repository, only what's in the image after a load (which may not be the same). To see what's in the repository, select a version in the published items tool, right click and 'Browse'. This will show the code in the repository in an old-style browser (not the RB). Could the method exist in multiple packages in the bundle? [hidden email] From: swcwork <[hidden email]> To: [hidden email] Sent: Fri, September 2, 2011 3:10:59 PM Subject: Re: [vwnc] VW 7.6 - method in image not in Store - how did it getthere? Thanks Randy & Terry, but the thing I am baffled by is that the version of the method in my image is not in Store at all. I have loaded our very first bundle published on 7.6 into a fresh 7.6 image, and the method in my image matches the current production image, but none of the 3 versions in store match the current implementation that I see. One of the old-timers on this project speculates that it might come from migrating from an earlier version of VW and migrating repositories, or that my versions browser is not seeing all the versions actually in Store. Wondering, Steve -- View this message in context: http://forum.world.st/VW-7-6-method-in-image-not-in-Store-how-did-it-get-there-tp3784143p3786943.html Sent from the VisualWorks mailing list archive at Nabble.com. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Randy Coulman
On Sep 2, 2011, at 6:45 51PM, Randy Coulman wrote: Or, another possible workflow, if you're used to other version control systems like Subversion: This is my usual workflow as well. Not because I'm used to subversion, but because I find the Store tools to be _horrible_ at visualizing merged branches, and when trying the other way, I always felt unsure main contained all production-ready code. Sadly, step #2 is usually slow enough to go get coffee, have a cigarette, and check out some select xkcd comics. (mainly http://xkcd.com/303/ ). Cheers, Henry _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by swcwork
One possibility is that one of the things you are loading from Store specifies a prerequisite, and VW is loading a parcel to fulfill that prerequisite. The method may be from the parcel, so outside of version control. The parcel will show up as a package, but its icon will be grey rather than yellow to indicate it isn't published in the current repository.
When you select the method, you can see which package it is in from the bottom right of the status bar. You can also make the browser show which classes and methods are in which parcels (or unparcelled) by choosing Browser | Parcel.
You can also check from the Change List to see when the method appeared: Press F12 to go to the launcher then F7 to open the Change List. In the Change List choose File | Recover Changes... , and if asked choose to go as far back as you can. Choose Find | Selector... and enter the selector of the method to filter the list to just versions of that method which have been compiled in this image's lifetime. If there's just one version, select it and turn the filter off by unchecking the Selector checkbox on the right. You can see from the context of the surrounding methods whether this was loaded as part of a package, or created at the end of a package load by some postLoad mechanism (as others suggested). If the method doesn't show up at all, it was loaded from a parcel (the parcel .pcl file contains an already-compiled version of the method, and the .pst file contains the source).
Happy hunting!
Steve From: [hidden email] on behalf of swcwork Sent: Fri 02/09/2011 23:10 To: [hidden email] Subject: Re: [vwnc] VW 7.6 - method in image not in Store - how did itgetthere? Thanks Randy & Terry, but the thing I am baffled by is that the version of _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
(Coming back from vacation
and catching up on vwnc)
With the method in Store not corresponding to the one in the image, it sounds to me like it might be related to an older Store bug, or actually series of bugs, that could result in the database version containing multiple different versions of the same method, confusing tools that try to deal with it. In current versions that really shouldn't happen any more, but in 7.6 it might, and it might also be a carryover from things published in even older versions. To check for this, do the following Browse Versions of the package in question. Select the version that's having the problem. Pop up the menu, then, with the Control key held down, select Browse. This is an easter egg that will give you an inspector on the Store.Package object. Run the expression "self searchAndDestroyDuplicateMethods" This will either pop up a dialog saying there were no duplicates, in which case this isn't the problem. Or it will give you a list of method versions. In the list of version methods, delete one of them. This will directly delete it from the database. You may also need to do the same thing for subsequent versions, as this defect may propagate to the next version published.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
We also ran into this problem for 7.7.1. So far we did nothing to
correct it. Glad to see a description of the problem. We have now upgraded to 7.8. I notice that #searchAndDestroyDuplicateMethods is gone. Does this mean that when upgrading Store to support 7.8, duplicate methods are removed by the upgrade process? Runar 2011/9/15 Alan Knight <[hidden email]>: > > With the method in Store not corresponding to the one in the image, it > sounds to me like it might be related to an older Store bug, or actually > series of bugs, that could result in the database version containing > multiple different versions of the same method, confusing tools that try to > deal with it. In current versions that really shouldn't happen any more, but > in 7.6 it might, and it might also be a carryover from things published in > even older versions. To check for this, do the following > > Browse Versions of the package in question. > Select the version that's having the problem. > Pop up the menu, then, with the Control key held down, select Browse. This > is an easter egg that will give you an inspector on the Store.Package > object. > Run the expression "self searchAndDestroyDuplicateMethods" > This will either pop up a dialog saying there were no duplicates, in which > case this isn't the problem. Or it will give you a list of method versions. > In the list of version methods, delete one of them. This will directly > delete it from the database. > You may also need to do the same thing for subsequent versions, as this > defect may propagate to the next version published. vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Publishing in 7.8 should get remove any
duplicates from the result, but won't fix up old packages in the
database. Actually, publishing even in versions before that should
mostly remove them, though there was a bug up until fairly recently that
it wouldn't consider the two methods to be the same if their protocols
were different, which is correct semantics for some situations, but not
this one.
That method is still available in 7.8 by loading the old Store objects, available in the obsolete directory under OldStoreTools. It would not be difficult to write something equivalent using the new database back-end, we just haven't done so.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Alan Knight-2
I tried the egg as described and it told me “no duplicates” – not sure whether to be happy or sad J From: Alan Knight [mailto:[hidden email]] With the method in Store not corresponding to the one in the image, it sounds to me like it might be related to an older Store bug, or actually series of bugs, that could result in the database version containing multiple different versions of the same method, confusing tools that try to deal with it. In current versions that really shouldn't happen any more, but in 7.6 it might, and it might also be a carryover from things published in even older versions. To check for this, do the following _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Steve Cline
|
Free forum by Nabble | Edit this page |