Levente, yes, that is correct. It actually once happened to me. I
updated to B in a development image (alpha). And I did not get the
update to C. So I had to revert the effect manually.
But as mentioned before, all is comparatively rare.

Regarding the history discussion a much more relevant point is that
some of the mcz or mcd files are actually quite large. Even just the
change of some 100 or 200 bytes often causes a 100..200kB update file
to be created.

--Hannes

On 10/19/18, Levente Uzonyi <leves at caesar.elte.hu> wrote:
> On Fri, 19 Oct 2018, H. Hirzel wrote:
>
>> Hi Bernard
>>
>> I think the explanation lies in the following
>>
>> Let us assume we have the following situation in the trunk
>>
>> A.
>> update n
>> update n-1
>> update n-2
>> update n-3
>>
>> Then an update n+1 is made:
>>
>> B.
>> update n+1
>> update n
>> update n-1
>> update n-2
>> update n-3
>>
>> and _immediately_ after it is discovered (within a few hours) that
>> update n+1 needs to be reverted and that is done so we have C
>>
>> C.
>> update n+ 2 = revert of update n+1
>> update n+1
>> update n
>> update n-1
>> update n-2
>> update n-3
>>
>> Then somebody detects this _BEFORE_ an update n+3 is made.
>> And deletes
>> update n+ 2 = revert of update n+1
>> update n+1
>>
>>
>> Then the situation is now
>>
>> D
>> update n
>> update n-1
>> update n-2
>> update n-3
>>
>> and this is indeed A.
>> No history to keep track of. The argument is that if an issue is
>> detected within a reasonable short time it does not need to be
>> recorded as history.
>
> Unfortunately that is not true if you had updated your image to B, but
> didn't update it to C in time.
> When the versions are removed (D), your image will stay tainted with the
> faulty version after updating. The only way to fix it is to manually
> revert to the previous version if that's possible at all.
> So, while D looks the same as A, D won't fix your image updated to B.
> You'll be stuck with the faulty version and merge conflicts in the future
> if you don't notice that.
> Had the two versions not be removed, the update process would be able to
> fix your image "automagically".
>
> Levente
>
>>
>> This was discussed a few months ago on the list.
>>
>> Cases where this happens are actually rare (about every 6 months) and
>> the general recommendation is to discuss things in the inbox first.
>>
>> --Hannes
>>
>>
>> On 10/19/18, Bernhard Pieber <bernhard at pieber.com> wrote:
>>> Hi Chris,
>>>
>>> It seems that you are quite annoyed and I assure you it is not my
>>> intention
>>> to annoy you any further. However, I would like to clarify one thing
>>> because
>>> it might make it easier for me to see where you come from. I have always
>>> thought that the moment something is pushed to trunk it becomes part of
>>> the
>>> history. Therefore I thought moving to Treated should only happen from
>>> Inbox. As you said "It never was history" you must mean somehing
>>> slightly
>>> different by history, right? I wonder what exactly?
>>>
>>> Cheers,
>>> Bernhard
>>>
>>>> Am 18.10.2018 um 02:43 schrieb Chris Muller <asqueaker at gmail.com>:
>>>>
>>>> On Wed, Oct 17, 2018 at 5:51 PM Bert Freudenberg <bert at freudenbergs.de>
>>>> wrote:
>>>> On Wed, Oct 17, 2018 at 3:00 PM Chris Muller <asqueaker at gmail.com>
>>>> wrote:
>>>> > the issue at stake here is the sanctity of the version history.
>>>>
>>>> "Sanctity."   If only you REALLY felt that way...    :(
>>>>
>>>> 🤔
>>>>
>>>> ...then you would want the history to be usable by reflecting
>>>> meaningful
>>>> changes, and not noise.
>>>>
>>>> It's not a raw tape of a tape-recorder, but our creation as a community
>>>> which is meant to be _useful_ to future consumers.
>>>>
>>>>
>>>> > It's untouchable. Think of it as immutable, append-only.
>>>>
>>>> Versions buried more than one or two deep are untouchable.  The top
>>>> version(s) are not.  Reverting to a prior version IS a use-case.
>>>> Deleting or moving a version IS a use-case.  There are UI commands to
>>>> do them.
>>>>
>>>> Nope. Not in Trunk. Only trunk admins can move versions. Because it is
>>>> a
>>>> last-resort option when all else fails.
>>>>
>>>> Yes, it is a last resort.  I'm sure we can do what's necessary to avoid
>>>> having to resort to it.
>>>>
>>>> The discussion is preserved in the mailing list, we don't need or want
>>>> it
>>>> in the trunk artifact.
>>>>
>>>> Removing a short-term in-and-out caused no harm.  Leaving it in does.
>>>>
>>>>
>>>> > Unless some commit actually breaks the update stream or does some
>>>> > other
>>>> > kind of major damage to users systems, it is always preferable to
>>>> > revert
>>>> > that commit by a subsequent commit.
>>>>
>>>> You have a penchant for stating things as "facts" without offering any
>>>> rationale whatsoever.  I could do something similar by only
>>>> saying,"it's rarely preferable to revert a commit by a subsequent
>>>> commit," with no basis.
>>>>
>>>> It's a commonly accepted practices in our field:
>>>>
>>>> "since so much work is local within your clone, you have a great deal
>>>> of
>>>> freedom to rewrite your history locally. However, once you push your
>>>> work,
>>>> it is a different story entirely, and you should consider pushed work
>>>> as
>>>> final unless you have good reason to change it. "
>>>>
>>>> Another "should" statement, and yes, sometimes there is good reason.
>>>>
>>>>
>>>>
>>>> > Patrick did that, and nobody was adversely affected.
>>>>
>>>> No!  We've been through this but, since you're Bert...   you're
>>>> conflating what you think is a "miniscule adverse effect" with "no
>>>> adverse effect".   In truth the  __breadth__  of the impact is not
>>>> miniscule:
>>>>
>>>>   - *Every client of every user* is adversely affected.
>>>>   - *Every dimension of the hardware* is affected (memory, storage,
>>>> network).
>>>>   - And software -- the usability of the code repository and ancestral
>>>> model.
>>>>   - *Every future user* and their hard drives, memorys, and networks
>>>> will also be adversely affected.
>>>>   - These adverse effects are _permanent_,
>>>>             even though they were conjured committed in only minutes
>>>> from a whimsy.
>>>>
>>>> Growing the universe by 0.1% is a big deal that advsersely affects
>>>> everybody whether they realize it or not.
>>>>
>>>> It was only by admin'ing, that nobody will be adversely affected.
>>>>
>>>> Sorry, I did not understand that you are worried about the physical
>>>> history size.
>>>>
>>>> Just because we don't need or want to enshrine 2K worth of "discussion"
>>>> in
>>>> the trunk artifact and add 2K*(that .mcz file + every future .mcz file)
>>>> *
>>>> (every copy of that file on a computer (package-cache, etc.) * (every
>>>> computer using Squeak), + (every running image memory) + (network
>>>> transit)
>>>> + (cpu) etc. etc., doesn't mean I'm actively "worried" about something.
>>>> It would be like me saying to you, "I did not understand that you are
>>>> worried about performance".  You may not be while still not necessarily
>>>> wanting to degrade something down when given a choice not to.
>>>>
>>>>
>>>> > Our rules about caution, restraint, doubt etc are to prevent these
>>>> > critical problems from occurring, not to keep the version history
>>>> > "pretty".
>>>>
>>>> Stop mischaracterizing the reason for maintaining a quality ancestry
>>>> and code repository.
>>>>
>>>> I did not get that, sorry again. I also do not agree with it. We should
>>>> fix our tools, not change history.
>>>>
>>>> It never was history.
>>>>
>>>> What about the real-world cost?
>>>>
>>>> Is there a single real-world benefit?  You haven't mentioned a single
>>>> compelling one, just "should".
>>>>
>>>>
>>>> > Also, I agree with Levente that your "inbox first" rule is not
>>>> > actually
>>>> > what we agreed upon. When we promote someone to core developer we
>>>> > trust
>>>> > them enough to judge whether to put stuff into trunk directly or not.
>>>>
>>>> Of course.  That's why it says "Guidelines" not "Rules".  This was
>>>> written to instill a conservative approach to committing.  It really
>>>> is a good approach for something you consider immutable.
>>>>
>>>> As I said before, "hopefully it won't happen very often, but if it
>>>> does..."  Rest assured, I don't enjoy being this "bad guy"...   :(
>>>>
>>>> In a community as small as ours I think it's more valuable to be
>>>> proactive
>>>> than conservative.
>>>> That was the original vision of the trunk development process -
>>>> removing
>>>> the gatekeepers, empowering individual developers. I still think that's
>>>> a
>>>> fundamentally good idea.
>>>>
>>>> Right, but this has nothing to do with any of that.  The state of the
>>>> trunk is still where you left it, and you are just as empowered as you
>>>> always were.  Nothing changed, there was an obvious "oops", it never
>>>> was
>>>> "history", so it was moved to Treated.  We should honor the spirit of
>>>> the
>>>> New Community Development Model.  The ancestry is not a tape-recorder
>>>> like
>>>> in git culture.
>>>>
>>>>  - Chris
>>>
>>>
>>>