Mantis - Squeak
Viewing Issue Advanced Details
4535 Janitorial major always 08-13-06 23:52 09-22-06 14:56
wiz  
 
normal  
closed 3.9  
fixed  
none    
none 3.9  
0004535: [Test] In 7052 (revised) Initial ChangeSet is still 'a ChangeSet named <no name -- garbage?>'
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

Notes
(0006610)
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)
wiz   
08-30-06 05:50   
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)
wiz   
09-08-06 02:13   
Reminder sent to: MarcusDenker, stef

This problem is in 7056 also.

(0007054)
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)
wiz   
09-16-06 06:20   
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)
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)
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)
ducasse   
09-22-06 14:56   
normally fixed in 7061
(0007323)
ducasse   
09-22-06 14:56   
in 7061