<div dir="ltr">Hi Chris, All,<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 17, 2018 at 3:09 PM, Chris Muller <span dir="ltr"><<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Hannes and all,<br>
<br>
What if someone submits code to trunk that is incompatible with the MIT license?<br></blockquote><div><br></div><div>Or, as I have done, mistakenly submitted a version that kills any image that loads it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Bottom-line:  Deleting a Version from trunk is an occasional use-case.<br>
Period.  It's part of the administrators UI and the above may not be<br>
the only occasion to need to do so.<br></blockquote><div><br></div><div>+1.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Just to make sure I've acknowleged and respected and evaluated all of<br>
your feedbacks:<br>
<br>
  1) "totally unnecessary",<br>
  2) "it would save almost nothing",<br>
  3) "break the images of everyone who had updated before the<br>
suggested removal of the verions",<br>
  4) "causes more problems than it solves."<br>
  5) "risky"<br>
<br>
With all due respect, generally, none of the above is true.  This is<br>
trunk development guys.  There is no meaningful "risk" and no<br>
meaningful breakage by properly deleting a bad commit.<br>
<br>
For the rare occasion when a bad commit happens, instead of shifting a<br>
permanent cost for it onto all future code consumption for all users,<br>
we should instead opt to incur only a very small and temporary cost<br>
(if any!) which is also limited in scope to the one or two people who<br>
may have updated since the bad commit.  If any special action is<br>
required, a note to squeak-dev, but people doing trunk development<br>
probably already know what to do.  So the impact of this is<br>
practically zero.<br></blockquote><div><br></div><div>+1.  In the early Spur days I needed to do this more than once.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hopefully bad commits won't happen very often, but if/when one does,<br>
you can expect me to continue to administer <a href="http://source.squeak.org" rel="noreferrer" target="_blank">source.squeak.org</a> with the<br>
care and respect it deserves -- like a delicate flower I want to keep<br>
healthy and preserved -- and continue to expect the same from you.<br>
IOW, I'm asking you to regard the health of the code repository with<br>
equal  importance to the health of the image.<br></blockquote><div><br></div><div>Glad to hear it :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best,<br>
  Chris<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
> An example of a problem (mentioned in my previous mail).<br>
><br>
> 1) I updated a my working image -> the HelpBrowser error occured.<br>
><br>
><br>
> 2) I updated my working image again, the note was<br>
><br>
>          Bypass Collections.kks.801.mcz for now because it leads to a problem<br>
>          opening the help browser.<br>
><br>
> --> The HelpBrowser error was still there. So it seems that I have<br>
> actually downloaded that Collections.kks.801.mcz which causes<br>
> problems. Which people who update later bypass.<br>
><br>
> I had to fix the issue manually. Because of the discussion in this<br>
> list it was easy to do. But out of context it would have been hard.<br>
><br>
> I agree with David that rewriting the history is risky.<br>
><br>
> Chris, I think your concern is the number of files which are<br>
> downloaded. That is indeed an issue. But it is not solved by having a<br>
> few less here and there. Because an incident like this HelpBrowser<br>
> breakage is comparatively rare.<br>
><br>
> The issues is for example that a new Morphic...mcz is big. For every<br>
> small change. Etoys for example could be split into different packages<br>
> thus reducing the download size.<br>
><br>
> Or even find a new way of just downloading a change set extracted from<br>
> the mcz instead of sending the whole mcz.<br>
><br>
><br>
> Returning to the main point of this thread and to sum up:<br>
><br>
> I would welcome if an updated version of the change which caused the<br>
> problems could be included as it is a good thing to fix.<br>
><br>
> --Hannes<br>
><br>
> On 7/17/18, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
> > On Mon, Jul 16, 2018 at 10:43 PM, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>><br>
> > wrote:<br>
> >> On Sat, Jul 14, 2018 at 05:42:32PM -0500, Chris Muller wrote:<br>
> >>> >> So, Levente/Chris/David,<br>
> >>> >> to fix this - do we delete the kks.801 from trunk, or alter kks.803 in<br>
> >>> >> the<br>
> >>> >> inbox (which seems to fix the issue) to have both dtl.802 (it's<br>
> >>> >> current<br>
> >>> >> parent) and kks.801 as both of its parents, which I believe<br>
> >>> >> would solve the 'multi head' issue.<br>
> >>> ><br>
> >>> > Neither. The proper solution is to create a new version which merges<br>
> >>> > the two<br>
> >>> > branches. If the fix is in kks.803, then xxx.804 will contain the fix<br>
> >>> > and<br>
> >>> > have both kks.803 and kks.801 as ancestors.<br>
> >>><br>
> >>> Wow.<br>
> >>><br>
> >>> > It is well known that the MC model was not designed for projects of<br>
> >>> > this size.<br>
> >>><br>
> >>> Right.<br>
> >>><br>
> >>> > But it would save almost nothing if that version were removed form the<br>
> >>> > ancestry.<br>
> >>><br>
> >>> Your suggestion above puts "almost nothing" at up to no less than<br>
> >>> three new versions in the ancestry for a one method fix.  It is not<br>
> >>> just about disk space, or memory space, or exacerbating our unscalable<br>
> >>> dimensions, but clutter, too.  Those are mey rationale's for deleting.<br>
> >>> I didn't catch any solid rationale for the idea of littering the<br>
> >>> ancestry when we have the opportunity not to.<br>
> >>><br>
> >><br>
> >> Levente,<br>
> >><br>
> >> You are right, I should have simply comitted a new version of the package.<br>
> >> I was trying to "bypass" the problem, but that was a mistake because it<br>
> >> caused problems for the update stream. It would have been better (as you<br>
> >> said) to have simply committed a new version.<br>
> >><br>
> >> Chris,<br>
> >><br>
> >> It is good to keep the update stream as clean as possible as you<br>
> >> explained,<br>
> >> but overall I think that Levente is right. In most cases, attempting to<br>
> >> rewrite version history causes more problems than it solves.<br>
> ><br>
> > What problem(s)?<br>
> ><br>
> ><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>