|Anonymous | Login||06-26-2019 09:48 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|
|Summary||0004535: [Test] In 7052 (revised) Initial ChangeSet is still 'a ChangeSet named <no name -- garbage?>'|
|Description||See issue 0004391.|
The fix apparently did not persist or was not applied correctly.
Included with this report is a test case for the symptom.
ChangeSetClass...alChangeSet.st [^] (449 bytes) 08-13-06 23:52
ChangeSet class-current.st [^] (408 bytes) 09-19-06 09:39
(0006610 - 131 - 167 - 167 - 167 - 167 - 167)
7054 has got it exactly right as far as I can tell.
This one is now closable.
Yours in service, -- Jerome Peace
(0006815 - 143 - 167 - 167 - 167 - 167 - 167)
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)
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)
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)
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 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)
"self new updateFrom7058"
(ChangeSet newChanges: (ChangeSet assuredChangeSetNamed: 'Unnamed')) .
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.
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)
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'!
"return the current changeset
assure first that we have a named changeset. To cure mantis 0004535. "
current isMoribund ifTrue:
(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)
|normally fixed in 7061|
(0007323 - 7 - 7 - 7 - 7 - 7 - 7)
|08-13-06 23:52||wiz||New Issue|
|08-13-06 23:52||wiz||File Added: ChangeSetClass...alChangeSet.st|
|08-14-06 05:22||wiz||Note Added: 0006610|
|08-16-06 09:36||MarcusDenker||Status||new => closed|
|08-16-06 09:36||MarcusDenker||Resolution||open => fixed|
|08-16-06 09:36||MarcusDenker||Fixed in Version||=> 3.9|
|08-30-06 05:50||wiz||Status||closed => feedback|
|08-30-06 05:50||wiz||Resolution||fixed => reopened|
|08-30-06 05:50||wiz||Note Added: 0006815|
|08-30-06 05:51||wiz||Note Edited: 0006815|
|09-08-06 02:13||wiz||Issue Monitored: MarcusDenker|
|09-08-06 02:13||wiz||Issue Monitored: stef|
|09-08-06 02:13||wiz||Note Added: 0006952|
|09-08-06 02:14||wiz||Note Edited: 0006952|
|09-11-06 08:37||wiz||Note Added: 0007054|
|09-16-06 06:20||wiz||Note Added: 0007184|
|09-16-06 11:23||wiz||Note Edited: 0007184|
|09-19-06 07:33||wiz||Note Added: 0007246|
|09-19-06 09:38||wiz||Note Added: 0007247|
|09-19-06 09:39||wiz||File Added: ChangeSet class-current.st|
|09-22-06 14:56||ducasse||Note Added: 0007322|
|09-22-06 14:56||ducasse||Status||feedback => closed|
|09-22-06 14:56||ducasse||Note Added: 0007323|
|09-22-06 14:56||ducasse||Resolution||reopened => fixed|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
92 total queries executed.|
50 unique queries executed.