0004535: [Test] In 7052 (revised) Initial ChangeSet is still 'a ChangeSet named <no name -- garbage?>'

Notes
(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

Issue History
Date Modified	Username	Field	Change
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

Relationships