This is definitely a new feature, 5.3 is in Feature Freeze.

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.

+1 for letting this simmer during the next development cycle.  Try-and-buy.

 - Chris

On Sat, Jan 25, 2020 at 10:54 AM David T. Lewis <lewis at mail.msen.com> wrote:

> On Fri, Jan 24, 2020 at 09:38:39PM -0800, Eliot Miranda wrote:
> > Hi Chris,
> >
> >    you may have the use case backwards. Here's what happened today.  I
> > opened Guille's VMMaker.oscog-GuillermoPolito.2676 which is in
> VMMakerInbox
> > and was shown many thousands of methods which said "different only in
> > timestamps".  My task was to find the methods that were not* different
> only
> > in time stamps.  I did this by implementing the filter operation (revert
> > unchanged methods spends a lot of time doing nothing; it does not remove
> > the noise).  Once I could see the four methods that differed other than
> by
> > timestamp (two of mine, two of Guille's) I could load Guille's methods,
> > effecting a manual merge.  I then committed something that didn't inherit
> > from VMMaker.oscog-GuillermoPolito.2676 (because if I did it would
> > introduce all those noisy non-differences), but did include the relevant
> > changes.  Does the menu item  make more sense now?
> >
>
> +1
>
> This is a very helpful change. We occasionally encounter the case of a
> Pharo user making a contribution to VMMaker (or OSProcess, or whatever)
> in which the MCZ is unusable due to Pharo issues, but the actual
> contribution
> is good. We do not want to discourage the contributions, but it is a real
> pain if you have to manually wade through a huge list of bogus "changes"
> in order to manually pick out one or two actual method changes. In addition
> to wasting time, it is also introducing risk of human error due to possibly
> overlooking a real change in a sea of non-changes.
>
> I would like to see this go into trunk as soon as possible. It is very
> low risk, so I would not mind seeing it go into 5.3 if no one objects.
>
> Dave
>
>
>
> > On Fri, Jan 24, 2020 at 6:56 PM Chris Muller <asqueaker at gmail.com>
> wrote:
> >
> > > Hi Eliot, this concerning to me from the aspect that committing a
> change
> > > with only the timestamp changed is something that shouldn't be done.
> Would
> > > it not pollute your version history with a bunch of "non-changes"
> noise?
> > >
> > >
> > >
> > > On Fri, Jan 24, 2020 at 8:17 PM <commits at source.squeak.org> wrote:
> > >
> > >> A new version of Monticello was added to project The Inbox:
> > >> http://source.squeak.org/inbox/Monticello-eem.709.mcz
> > >>
> > >> ==================== Summary ====================
> > >>
> > >> Name: Monticello-eem.709
> > >> Author: eem
> > >> Time: 24 January 2020, 6:17:42.907101 pm
> > >> UUID: ec11ed59-223d-4b58-aa08-c214e1ceb2e9
> > >> Ancestors: Monticello-cmm.708
> > >>
> > >> Provide 'filter out unchanged methods...' to ignore any timestamp-only
> > >> changes.
> > >>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200128/fb255cc2/attachment.html>