Updates seem broken again

Whilst attempting to update my (spur) image in order to be able to save the HandMorph>dragging related change I mentioned recently I discovered that we’ve broken something in the update stream again.

As it gets to Kernel.spur-dtl.850 things start to complain; an MC merge window appears but I cannot use the ‘all newer’ etc options. Selecting the first clash and hitting ‘Reject’ works enough to let me reject all the changes - which looks sensible since they seem to be older than the in-image versions - and then continue the merge. This repeats many times.

Any attempt to use ‘All Newer’ et al. opens a dNU in MCConflict>isRemoteNewer because ‘self localDefinition’ is nil and of course does not understand #fullTimeStamp.

Sigh.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Fractured Idiom:- VENI, VIDI, VICE - I came, I saw, I partied.

> On 08-01-2016, at 7:36 PM, tim Rowledge <[hidden email]> wrote:
>
> Whilst attempting to update my (spur) image in order to be able to save the HandMorph>dragging related change I mentioned recently I discovered that we’ve broken something in the update stream again.

Just to add some puzzlement, I went all the way back to a 5.0 image from the all-in-one package, set the URL for the update stream to trunk and updated it. That went ok (aside from that ‘scare the hell out of you’ notifier regarding empty packages) and claimed to finish. At update 15546.

My working image - the one I wanted to update - is already at 15566. However, the update list was ‘update.spur’ rather than just ‘update’ so I tried again from fresh…

Nope, gets back to the same issue originally reported.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- If he were any more stupid, he'd have to be watered twice a week.

Aaaaand even setting the update related preference to not use merge makes no difference - maybe that preference is actually ignored?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Ignorant, and proud of it.

Some of the problem is now understood - the image with problems has the ‘update.spur’ update map name. Apparently it shouldn’t.

So then the interesting question is where it came from since I really can’t remember setting it myself - I’ve never even noticed it as an option before! The only suspect I can find at the moment is SpurBootstrapMonticelloPackagePatcher>spurConfigurationOf:forRepository: dated 'eem 2/3/2015 12:59’ or uploadNewerSpurConfigurationsInTrunk dated 'eem 10/16/2014 13:21’ neither of which are not even in the image nor changes of the system that is having problems.

A trunk spur 5.0 image does update and appears to get to the latest changes to Mutex etc. Quite what happened and why my prior working image thought it was at update 15566 I don’t know. It’s been one of those weeks.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Never underestimate the bandwidth of a station wagon full of tapes.

> On 08-01-2016, at 8:56 PM, tim Rowledge <[hidden email]> wrote:
>
> Some of the problem is now understood - the image with problems has the ‘update.spur’ update map name. Apparently it shouldn’t.

And problem solved; at some point in the past - early spur development I guess - I saved my preferences when ‘update.spur' was the right thing to have in there. Loading those preferences is where it came from. At least I know what happened now.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Hardware: The parts of a computer system that can be kicked.