Anonymous | Login | 01-15-2021 17:29 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
0004535 | [Squeak] Janitorial | major | always | 08-13-06 23:52 | 09-22-06 14:56 | ||||
Reporter | wiz | View Status | public | ||||||
Assigned To | |||||||||
Priority | normal | Resolution | fixed | ||||||
Status | closed | Product Version | 3.9 | ||||||
Summary | 0004535: [Test] In 7052 (revised) Initial ChangeSet is still 'a ChangeSet named <no name -- garbage?>' | ||||||||
Description | See issue 0004391. | ||||||||
Additional Information |
The fix apparently did not persist or was not applied correctly. Included with this report is a test case for the symptom. |
||||||||
Attached Files |
![]() ![]() |
||||||||
|
![]() |
|
(0006610 - 131 - 167 - 167 - 167 - 167 - 167) wiz 08-14-06 05:22 |
7054 has got it exactly right as far as I can tell. Good work. This one is now closable. Yours in service, -- Jerome Peace |
(0006815 - 143 - 167 - 167 - 167 - 167 - 167) wiz 08-30-06 05:50 edited on: 08-30-06 05:51 |
This is back in 7055. I would suggest including the test in future versions. This seems to crop up. Especially when sources are condensed. |
(0006952 - 31 - 43 - 43 - 43 - 43 - 43) wiz 09-08-06 02:13 edited on: 09-08-06 02:14 |
Reminder sent to: MarcusDenker, stef This problem is in 7056 also. |
(0007054 - 458 - 548 - 548 - 548 - 548 - 548) wiz 09-11-06 08:37 |
Reminder sent to: MarcusDenker Hi Stef, Marcus This bug is still in 7057. If its any help when I open a dual change sorter the left side has no change set selected the right side has the unnamed selected. When I open a single change sorter the change set is unselected. Something is not setting up the current changeset. Or unsetting it. I find it amusing and frustrating that you have not installed or run the test to detect this. Yours in service, -- Jerome Peace |
(0007184 - 778 - 922 - 922 - 922 - 922 - 922) wiz 09-16-06 06:20 edited on: 09-16-06 11:23 |
Also in 7058. Sent note to squeakdev this time hoping to get some attention to this. And after reading the responses I dug in and did some research. The magic invocation is: (ChangeSet newChanges: (ChangeSet assuredChangeSetNamed: 'Unnamed')) . That will set the current changeset to the appropriate one creating it if it doesn't exist. If this doesn't work when you try it look at what happens after you do it. If the current changeset is removed it is still the current changeset but its name will be set to nil by the wither message. One is supposed to check for okayToRemoveNotifying: false to insure a changeset is not attached to a project or is not the current changeset before a removal operation. Yours in service, --Jerome Peace |
(0007246 - 965 - 1336 - 1336 - 1336 - 1336 - 1336) wiz 09-19-06 07:33 |
Hi Stef, updateFrom7058 "self new updateFrom7058" (ChangeSet newChanges: (ChangeSet assuredChangeSetNamed: 'Unnamed')) . "Postscript: ." ScriptLoader new updateFrom7058. What you did looks like it should work. I tried two simpler version of it. And that has confirmed the problem. From a fresh version of 7058 I wrote out the Scriptloader>>updateFrom7058 method with the postscript (see above) (I left out the update from repository stuff to simplify the test and save time) and read it back in. (That left the problem intact.) ChangeSet current was still moribund. Then I tried the same thing with just the (ChangeSet newChanges: (ChangeSet > assuredChangeSetNamed: 'Unnamed')) . in the postscript. Same problem. And of course it works fine either way from a doit outside of the cs. ChangeSet must be doing something special to not allow the updating of current from within a changeset postscript. |
(0007247 - 1330 - 1629 - 1629 - 1893 - 1893 - 1893) wiz 09-19-06 09:38 |
Well sure enough the install method !ChangeSet class>>newChangesFromStream: aStream named: aName was carefully perserving the current changeset around the install. The postscript could not fix anything. Whatever it did to the current change set was undone. The Ironman fix is to make sure Changeset current always returns a valid changeset. so I modified the accessor: 'From Squeak3.9gamma of ''23 July 2006'' [latest update: 0007058] on 19 September 2006 at 3:22:08 am'! !ChangeSet class methodsFor: 'current changeset' stamp: 'wiz 9/19/2006 03:21'! current "return the current changeset assure first that we have a named changeset. To cure mantis 0004535. " current isMoribund ifTrue: [(ChangeSet newChanges: (ChangeSet assuredChangeSetNamed: 'Unnamed'))] . ^ current! ! This works because #newChanges: accesses current directly (If it ever chooses to use the indirect accessor this will be an infinite loop. Fortunately it is sane and this fix will work.) Once this patch is made any new changesorter will show a reasonable changeset and changes won't be lost. Now there is another bug left to find. Which part of the load script or the condense changes is creating a moribund current ChangeSet? I.E. where do things go wrong? That does not need be solved right away. This did. |
(0007322 - 22 - 22 - 22 - 22 - 22 - 22) ducasse 09-22-06 14:56 |
normally fixed in 7061 |
(0007323 - 7 - 7 - 7 - 7 - 7 - 7) ducasse 09-22-06 14:56 |
in 7061 |
Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
92 total queries executed. 50 unique queries executed. |