An example of a problem (mentioned in my previous mail).

1) I updated a my working image -> the HelpBrowser error occured.


2) I updated my working image again, the note was

         Bypass Collections.kks.801.mcz for now because it leads to a problem
         opening the help browser.

--> The HelpBrowser error was still there. So it seems that I have
actually downloaded that Collections.kks.801.mcz which causes
problems. Which people who update later bypass.

I had to fix the issue manually. Because of the discussion in this
list it was easy to do. But out of context it would have been hard.

I agree with David that rewriting the history is risky.

Chris, I think your concern is the number of files which are
downloaded. That is indeed an issue. But it is not solved by having a
few less here and there. Because an incident like this HelpBrowser
breakage is comparatively rare.

The issues is for example that a new Morphic...mcz is big. For every
small change. Etoys for example could be split into different packages
thus reducing the download size.

Or even find a new way of just downloading a change set extracted from
the mcz instead of sending the whole mcz.


Returning to the main point of this thread and to sum up:

I would welcome if an updated version of the change which caused the
problems could be included as it is a good thing to fix.

--Hannes

On 7/17/18, Chris Muller <asqueaker at gmail.com> wrote:
> On Mon, Jul 16, 2018 at 10:43 PM, David T. Lewis <lewis at mail.msen.com>
> wrote:
>> On Sat, Jul 14, 2018 at 05:42:32PM -0500, Chris Muller wrote:
>>> >> So, Levente/Chris/David,
>>> >> to fix this - do we delete the kks.801 from trunk, or alter kks.803 in
>>> >> the
>>> >> inbox (which seems to fix the issue) to have both dtl.802 (it's
>>> >> current
>>> >> parent) and kks.801 as both of its parents, which I believe
>>> >> would solve the 'multi head' issue.
>>> >
>>> > Neither. The proper solution is to create a new version which merges
>>> > the two
>>> > branches. If the fix is in kks.803, then xxx.804 will contain the fix
>>> > and
>>> > have both kks.803 and kks.801 as ancestors.
>>>
>>> Wow.
>>>
>>> > It is well known that the MC model was not designed for projects of
>>> > this size.
>>>
>>> Right.
>>>
>>> > But it would save almost nothing if that version were removed form the
>>> > ancestry.
>>>
>>> Your suggestion above puts "almost nothing" at up to no less than
>>> three new versions in the ancestry for a one method fix.  It is not
>>> just about disk space, or memory space, or exacerbating our unscalable
>>> dimensions, but clutter, too.  Those are mey rationale's for deleting.
>>> I didn't catch any solid rationale for the idea of littering the
>>> ancestry when we have the opportunity not to.
>>>
>>
>> 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.
>
> What problem(s)?
>
>