<div dir="ltr"><div>This is definitely a new feature, 5.3 is in Feature Freeze.</div><div><br></div><div>It's important this feature does not get inherited by SaveDialog since the functionality could be harmful if used there, but it looks like it does.  It sounds like a VM-Pharo-specific process issue which may have more than one solution.  Or, it may be better implemented as an extension in VMMaker than the base tools.<br></div><div><div></div></div><div><br></div><div><div><div>+1 for letting this simmer during the next development cycle.  Try-and-buy.<br></div><div></div></div><div></div></div><div><br></div><div> - Chris</div><div dir="ltr"><br></div><div dir="ltr">On Sat, Jan 25, 2020 at 10:54 AM David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jan 24, 2020 at 09:38:39PM -0800, Eliot Miranda wrote:<br>
> Hi Chris,<br>
> <br>
>    you may have the use case backwards. Here's what happened today.  I<br>
> opened Guille's VMMaker.oscog-GuillermoPolito.2676 which is in VMMakerInbox<br>
> and was shown many thousands of methods which said "different only in<br>
> timestamps".  My task was to find the methods that were not* different only<br>
> in time stamps.  I did this by implementing the filter operation (revert<br>
> unchanged methods spends a lot of time doing nothing; it does not remove<br>
> the noise).  Once I could see the four methods that differed other than by<br>
> timestamp (two of mine, two of Guille's) I could load Guille's methods,<br>
> effecting a manual merge.  I then committed something that didn't inherit<br>
> from VMMaker.oscog-GuillermoPolito.2676 (because if I did it would<br>
> introduce all those noisy non-differences), but did include the relevant<br>
> changes.  Does the menu item  make more sense now?<br>
> <br>
<br>
+1<br>
<br>
This is a very helpful change. We occasionally encounter the case of a<br>
Pharo user making a contribution to VMMaker (or OSProcess, or whatever)<br>
in which the MCZ is unusable due to Pharo issues, but the actual contribution<br>
is good. We do not want to discourage the contributions, but it is a real<br>
pain if you have to manually wade through a huge list of bogus "changes"<br>
in order to manually pick out one or two actual method changes. In addition<br>
to wasting time, it is also introducing risk of human error due to possibly<br>
overlooking a real change in a sea of non-changes.<br>
<br>
I would like to see this go into trunk as soon as possible. It is very<br>
low risk, so I would not mind seeing it go into 5.3 if no one objects.<br>
<br>
Dave<br>
<br>
<br>
<br>
> On Fri, Jan 24, 2020 at 6:56 PM Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>> wrote:<br>
> <br>
> > Hi Eliot, this concerning to me from the aspect that committing a change<br>
> > with only the timestamp changed is something that shouldn't be done.  Would<br>
> > it not pollute your version history with a bunch of "non-changes" noise?<br>
> ><br>
> ><br>
> ><br>
> > On Fri, Jan 24, 2020 at 8:17 PM <<a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a>> wrote:<br>
> ><br>
> >> A new version of Monticello was added to project The Inbox:<br>
> >> <a href="http://source.squeak.org/inbox/Monticello-eem.709.mcz" rel="noreferrer" target="_blank">http://source.squeak.org/inbox/Monticello-eem.709.mcz</a><br>
> >><br>
> >> ==================== Summary ====================<br>
> >><br>
> >> Name: Monticello-eem.709<br>
> >> Author: eem<br>
> >> Time: 24 January 2020, 6:17:42.907101 pm<br>
> >> UUID: ec11ed59-223d-4b58-aa08-c214e1ceb2e9<br>
> >> Ancestors: Monticello-cmm.708<br>
> >><br>
> >> Provide 'filter out unchanged methods...' to ignore any timestamp-only<br>
> >> changes.<br>
> >><br>
<br>
<br>
</blockquote></div></div>