So it is about the mcd files in the package cache? Or are the 100..200kB added to the image as well?

Bernhard

> Am 19.10.2018 um 23:00 schrieb H. Hirzel <hannes.hirzel at gmail.com>:
> 
> 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
>>>> 
>>>> 
>>>> 
>