Chris,

I think you are being a bit too invasive here. Trying to rewrite the version history after the fact is usually a bad idea (*) unless it is an emergency situation in which someone has inadvertently broken the update stream. That was not the case here, and Tobias had already taken the appropriate action to revert the method.

Aside from emergencies, I think it's better to leave the version history as it is, warts and all. If this results in our tools and/or update stream being too slow, then let's work on fixing that problem.

Dave

(*) Among the unintended consequences of modifying the version history after the fact is that it makes a mess in one of my own projects (http://www.squeaksource.com/TrunkUpdateStreamV3). I will untangle it, but I would be happier if I didn't need to.

Dave

On Sat, Sep 15, 2018 at 03:24:42PM -0500, Chris Muller wrote:

As promised, I cleaned this in-and-out clutter out of the main trunk, in to the Inbox.

If you'd already updated your trunk image, please revert to or load Collections-cmm.805 from the repository.

• Chris

On Sat, Sep 15, 2018 at 3:17 PM commits@source.squeak.org wrote:

...

Chris Muller uploaded a new version of Collections to project The Inbox: http://source.squeak.org/inbox/Collections-topa.806.mcz

==================== Summary ====================

Name: Collections-topa.806 Author: topa Time: 12 September 2018, 3:28:40.687052 pm UUID: 46b95db5-a773-4113-92f0-5ee905404b49 Ancestors: Collections-cmm.805

Fix separators to include U+00A0 (no break space)

Thanks Ron!

=============== Diff against Collections-cmm.805 ===============

Item was changed: ----- Method: Character class>>separators (in category 'instance creation') ----- separators

•   "Answer a collection of space-like separator characters.
  

•   Note that we do not consider spaces in >8bit code points yet.
  

•   "
  

•   "Answer a collection of the standard ASCII separator characters."
  
  

•   ^ #(9 "tab"
  

•   ^ #(32 "space"
  

•           13 "cr"
  

•           9 "tab"
            10 "line feed"
  

•           12 "form feed"
  

•           13 "cr"
  

•           32 "space"
  

•           160 "non-breaking space, see Unicode Z general category")
  

•           collect: [:v | Character value: v] as: String
  

• " To be considered:
• 16r1680 OGHAM SPACE MARK
• 16r2000 EN QUAD
• 16r2001 EM QUAD
• 16r2002 EN SPACE
• 16r2003 EM SPACE
• 16r2004 THREE-PER-EM SPACE
• 16r2005 FOUR-PER-EM SPACE
• 16r2006 SIX-PER-EM SPACE
• 16r2007 FIGURE SPACE
• 16r2008 PUNCTUATION SPACE
• 16r2009 THIN SPACE
• 16r200A HAIR SPACE
• 16r2028 LINE SEPARATOR
• 16r2029 PARAGRAPH SEPARATOR
• 16r202F NARROW NO-BREAK SPACE
• 16r205F MEDIUM MATHEMATICAL SPACE
• 16r3000 IDEOGRAPHIC SPACE
• "!

•           12 "form feed")
  

•           collect: [:v | Character value: v] as: String!
  
  

Item was changed:

• (PackageInfo named: 'Collections') postscript: 'CharacterSet cleanUp: false.'!

• (PackageInfo named: 'Collections') postscript: 'Character initializeClassificationTable'!

On Sat, Sep 15, 2018 at 09:15:59PM -0500, Chris Muller wrote:

Hi Dave,

...

I think you are being a bit too invasive here. Trying to rewrite the version history after the fact is usually a bad idea (*) unless it is an emergency situation in which someone has inadvertently broken the update stream. That was not the case here, and Tobias had already taken the appropriate action to revert the method.

Deleting a version is a valid use case and one of those things we just have to deal with occasionally. It's not invasive, nothing was rewritten, and it's a very good idea.

...

Aside from emergencies, I think it's better to leave the version history as it is, warts and all. If this results in our tools and/or update stream being too slow, then let's work on fixing that problem.

With all due respect, please review our recent discussion [1] about this where I explained how it's about more than update stream being too slow... it will save me a lot of (re)typing.

[1] -- See thread: "This is the Help System failure..."

Hi Chris,

Yes I do remember the discussion. This was a case where I learned the hard way that trying to fix the version history can have unintended consequences, and that it generally best to avoid doing this except as a last resort. I made a mistake.

I now agree with what Levente said in that thread:

"Removing something from the Trunk should be the last resort. That would be totally unnecessary in this case."

http://lists.squeakfoundation.org/pipermail/squeak-dev/2018-July/199578.html

And my conclusion later in the thread was this:

Levente,

You are right, I should have simply comitted a new version of the package. I was trying to "bypass" the problem, but that was a mistake because it caused problems for the update stream. It would have been better (as you said) to have simply committed a new version.

Chris,

It is good to keep the update stream as clean as possible as you explained, but overall I think that Levente is right. In most cases, attempting to rewrite version history causes more problems than it solves.

http://lists.squeakfoundation.org/pipermail/squeak-dev/2018-July/199595.html

Dave