The Inbox: Monticello-eem.709.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

The Inbox: Monticello-eem.709.mcz

commits-2
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.

=============== Diff against Monticello-cmm.708 ===============

Item was added:
+ ----- Method: MCOperationsBrowser>>filterOutUnchangedMethods (in category 'actions') -----
+ filterOutUnchangedMethods
+ "Remove from the list methods that only have changed timestamps"
+ | unchangedMethods |
+ unchangedMethods := self unchangedMethods.
+ (self confirm: ('Ignore {1} methods that only differ in timestamp?' translated
+ format: {unchangedMethods size}))
+ ifTrue:
+ [items := items reject: [:op| op isUnchangedMethod].
+ self changed: #list]
+ !

Item was changed:
  ----- Method: MCOperationsBrowser>>methodListMenu: (in category 'menus') -----
  methodListMenu: aMenu
  selection ifNotNil:
  [aMenu addList: #(
  ('install' installSelection)
  ('revert (x)' revertSelection)
  ('browse origin' browseSelectionOrigin)
  -)].
  self unchangedMethods ifNotEmpty:
  [aMenu addList: #(
  ('revert unchanged methods...' revertUnchangedMethods)
+ ('filter out unchanged methods...' filterOutUnchangedMethods)
  -)].
  super methodListMenu: aMenu.
  ^ aMenu!

Item was changed:
  ----- Method: MCOperationsBrowser>>revertUnchangedMethods (in category 'actions') -----
  revertUnchangedMethods
  "revert methods that only have changed timestamps"
  | loader unchangedMethods |
+ unchangedMethods := self unchangedMethods.
+ (self confirm: ('Revert {1} methods that only differ in timestamp?' translated
+ format: {unchangedMethods size}))
+ ifTrue:
+ [loader := MCPackageLoader new.
- unchangedMethods := items select: [:op | op isUnchangedMethod].
- (self confirm: ('Revert {1} methods that only differ in timestamp?' translated format: {unchangedMethods size}))
- ifTrue: [
- loader := MCPackageLoader new.
  unchangedMethods do: [:op | op inverse applyTo: loader].
  loader loadWithName: self changeSetNameForInstall].
  !


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-eem.709.mcz

Chris Muller-3
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 <[hidden email]> 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.

=============== Diff against Monticello-cmm.708 ===============

Item was added:
+ ----- Method: MCOperationsBrowser>>filterOutUnchangedMethods (in category 'actions') -----
+ filterOutUnchangedMethods
+       "Remove from the list methods that only have changed timestamps"
+       | unchangedMethods |
+       unchangedMethods := self unchangedMethods.
+       (self confirm: ('Ignore {1} methods that only differ in timestamp?' translated
+               format: {unchangedMethods size}))
+               ifTrue:
+                       [items := items reject: [:op| op isUnchangedMethod].
+                        self changed: #list]
+ !

Item was changed:
  ----- Method: MCOperationsBrowser>>methodListMenu: (in category 'menus') -----
  methodListMenu: aMenu
        selection ifNotNil:
                [aMenu addList: #(
                        ('install'       installSelection)
                        ('revert (x)'    revertSelection)
                        ('browse origin' browseSelectionOrigin)
                        -)].
        self unchangedMethods ifNotEmpty:
                [aMenu addList: #(
                        ('revert unchanged methods...'  revertUnchangedMethods)
+                       ('filter out unchanged methods...'      filterOutUnchangedMethods)
                        -)].
        super methodListMenu: aMenu.
        ^ aMenu!

Item was changed:
  ----- Method: MCOperationsBrowser>>revertUnchangedMethods (in category 'actions') -----
  revertUnchangedMethods
        "revert methods that only have changed timestamps"
        | loader unchangedMethods |
+       unchangedMethods := self unchangedMethods.
+       (self confirm: ('Revert {1} methods that only differ in timestamp?' translated
+               format: {unchangedMethods size}))
+               ifTrue:
+                       [loader := MCPackageLoader new.
-       unchangedMethods := items select: [:op | op isUnchangedMethod].
-       (self confirm: ('Revert {1} methods that only differ in timestamp?' translated format: {unchangedMethods size}))
-               ifTrue: [
-                       loader := MCPackageLoader new.
                        unchangedMethods do: [:op | op inverse applyTo: loader].
                        loader loadWithName: self changeSetNameForInstall].
  !




Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-eem.709.mcz

Eliot Miranda-2
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?

On Fri, Jan 24, 2020 at 6:56 PM Chris Muller <[hidden email]> 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 <[hidden email]> 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.

=============== Diff against Monticello-cmm.708 ===============

Item was added:
+ ----- Method: MCOperationsBrowser>>filterOutUnchangedMethods (in category 'actions') -----
+ filterOutUnchangedMethods
+       "Remove from the list methods that only have changed timestamps"
+       | unchangedMethods |
+       unchangedMethods := self unchangedMethods.
+       (self confirm: ('Ignore {1} methods that only differ in timestamp?' translated
+               format: {unchangedMethods size}))
+               ifTrue:
+                       [items := items reject: [:op| op isUnchangedMethod].
+                        self changed: #list]
+ !

Item was changed:
  ----- Method: MCOperationsBrowser>>methodListMenu: (in category 'menus') -----
  methodListMenu: aMenu
        selection ifNotNil:
                [aMenu addList: #(
                        ('install'       installSelection)
                        ('revert (x)'    revertSelection)
                        ('browse origin' browseSelectionOrigin)
                        -)].
        self unchangedMethods ifNotEmpty:
                [aMenu addList: #(
                        ('revert unchanged methods...'  revertUnchangedMethods)
+                       ('filter out unchanged methods...'      filterOutUnchangedMethods)
                        -)].
        super methodListMenu: aMenu.
        ^ aMenu!

Item was changed:
  ----- Method: MCOperationsBrowser>>revertUnchangedMethods (in category 'actions') -----
  revertUnchangedMethods
        "revert methods that only have changed timestamps"
        | loader unchangedMethods |
+       unchangedMethods := self unchangedMethods.
+       (self confirm: ('Revert {1} methods that only differ in timestamp?' translated
+               format: {unchangedMethods size}))
+               ifTrue:
+                       [loader := MCPackageLoader new.
-       unchangedMethods := items select: [:op | op isUnchangedMethod].
-       (self confirm: ('Revert {1} methods that only differ in timestamp?' translated format: {unchangedMethods size}))
-               ifTrue: [
-                       loader := MCPackageLoader new.
                        unchangedMethods do: [:op | op inverse applyTo: loader].
                        loader loadWithName: self changeSetNameForInstall].
  !





--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-eem.709.mcz

David T. Lewis
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 <[hidden email]> 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 <[hidden email]> 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.
> >>


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-eem.709.mcz

Chris Muller-4
In reply to this post by Eliot Miranda-2
Yes.  Oh man, that sounds rather nightmarish.  I didn't follow the recent discussion about timestamps, just glad to know we're still trying to hang on to them!

Regards,
  Chris

On Fri, Jan 24, 2020 at 11:38 PM Eliot Miranda <[hidden email]> 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?

On Fri, Jan 24, 2020 at 6:56 PM Chris Muller <[hidden email]> 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 <[hidden email]> 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.

=============== Diff against Monticello-cmm.708 ===============

Item was added:
+ ----- Method: MCOperationsBrowser>>filterOutUnchangedMethods (in category 'actions') -----
+ filterOutUnchangedMethods
+       "Remove from the list methods that only have changed timestamps"
+       | unchangedMethods |
+       unchangedMethods := self unchangedMethods.
+       (self confirm: ('Ignore {1} methods that only differ in timestamp?' translated
+               format: {unchangedMethods size}))
+               ifTrue:
+                       [items := items reject: [:op| op isUnchangedMethod].
+                        self changed: #list]
+ !

Item was changed:
  ----- Method: MCOperationsBrowser>>methodListMenu: (in category 'menus') -----
  methodListMenu: aMenu
        selection ifNotNil:
                [aMenu addList: #(
                        ('install'       installSelection)
                        ('revert (x)'    revertSelection)
                        ('browse origin' browseSelectionOrigin)
                        -)].
        self unchangedMethods ifNotEmpty:
                [aMenu addList: #(
                        ('revert unchanged methods...'  revertUnchangedMethods)
+                       ('filter out unchanged methods...'      filterOutUnchangedMethods)
                        -)].
        super methodListMenu: aMenu.
        ^ aMenu!

Item was changed:
  ----- Method: MCOperationsBrowser>>revertUnchangedMethods (in category 'actions') -----
  revertUnchangedMethods
        "revert methods that only have changed timestamps"
        | loader unchangedMethods |
+       unchangedMethods := self unchangedMethods.
+       (self confirm: ('Revert {1} methods that only differ in timestamp?' translated
+               format: {unchangedMethods size}))
+               ifTrue:
+                       [loader := MCPackageLoader new.
-       unchangedMethods := items select: [:op | op isUnchangedMethod].
-       (self confirm: ('Revert {1} methods that only differ in timestamp?' translated format: {unchangedMethods size}))
-               ifTrue: [
-                       loader := MCPackageLoader new.
                        unchangedMethods do: [:op | op inverse applyTo: loader].
                        loader loadWithName: self changeSetNameForInstall].
  !





--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-eem.709.mcz

Chris Muller-3
In reply to this post by David T. Lewis
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.
> >>




Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-eem.709.mcz

Jakob Reschke
Chris Muller <[hidden email]> schrieb am Mi., 29. Jan. 2020, 03:57:

It's important this feature does not get inherited by SaveDialog since the functionality could be harmful if used there

How so? What is bad about wittingly ignoring non-changes during save? You called it pollution yourself.

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.

The problem will apply to any package that is co-developped by Squeak and Pharo guys and that is exchanged via Monticello. It cannot be solved in VMMaker because the issue lies in Monticello or rather Pharo's shift of tools.

The other solution I see is to auto-generate missing timestamps from the version info in the ancestry whenever the snapshot of a version is computed. They will only be as granular as the rate of commits of course. And Monticello storing as it does, the operation will not be efficient in general because you have to download all the snapshots until you find when each method that is missing timestamps was last changed or still had a timestamp.

Kind regards,
Jakob


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-eem.709.mcz

Nicolas Cellier


Le mer. 29 janv. 2020 à 08:04, Jakob Reschke <[hidden email]> a écrit :
Chris Muller <[hidden email]> schrieb am Mi., 29. Jan. 2020, 03:57:

It's important this feature does not get inherited by SaveDialog since the functionality could be harmful if used there

How so? What is bad about wittingly ignoring non-changes during save? You called it pollution yourself.

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.

The problem will apply to any package that is co-developped by Squeak and Pharo guys and that is exchanged via Monticello. It cannot be solved in VMMaker because the issue lies in Monticello or rather Pharo's shift of tools.

The other solution I see is to auto-generate missing timestamps from the version info in the ancestry whenever the snapshot of a version is computed. They will only be as granular as the rate of commits of course. And Monticello storing as it does, the operation will not be efficient in general because you have to download all the snapshots until you find when each method that is missing timestamps was last changed or still had a timestamp.

Hi Jakob,
however there is a quick case: if code is unchanged wrt image working copy, then take timestamp from working copy...

Kind regards,
Jakob



Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-eem.709.mcz

Chris Muller-3
In reply to this post by Jakob Reschke
On Wed, Jan 29, 2020 at 1:04 AM Jakob Reschke <[hidden email]> wrote:
Chris Muller <[hidden email]> schrieb am Mi., 29. Jan. 2020, 03:57:

It's important this feature does not get inherited by SaveDialog since the functionality could be harmful if used there

How so? What is bad about wittingly ignoring non-changes during save? You called it pollution yourself.

Jakob, your language is confusing because "Ignore" is the other command there that, yes, would cause them to not be committed.

But what is being added is a 'filter out unchanged methods from the list...', which, IIUC, would only remove them from the list, making them invisible, but not "Ignore" them.  So, if used on the Save dialog, would they be included in the commit?

If so, then for that reason, IMO, it should somehow be restricted to general OperationsBrowser (i.e., as when clicking on the Changes button).

I tried installing it and looking for the menu additions, but coudln't find them I only had few minutes...
 

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.

The problem will apply to any package that is co-developped by Squeak and Pharo guys and that is exchanged via Monticello. It cannot be solved in VMMaker because the issue lies in Monticello or rather Pharo's shift of tools.

The other solution I see is to auto-generate missing timestamps from the version info in the ancestry whenever the snapshot of a version is computed. They will only be as granular as the rate of commits of course. And Monticello storing as it does, the operation will not be efficient in general because you have to download all the snapshots until you find when each method that is missing timestamps was last changed or still had a timestamp.

Kind regards,
Jakob



Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-eem.709.mcz

David T. Lewis
On Wed, Jan 29, 2020 at 04:39:29PM -0600, Chris Muller wrote:
>
> I tried installing it and looking for the menu additions, but coudln't find
> them I only had few minutes...
>

The menu option is presented only if there actually are method changes
that differ only in timestamp.

To see an example, open the http://www.squeaksource.com/Alien repository,
look at the Alien-Core package, select Alien-Core-TorstenBergmann.101.mcz,
then click the History button. Look at the changes between this version
and its predecessor, Alien-Core-tbn.100.

Right-click on the methods list and you will be able to try using the
new menu pick.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-eem.709.mcz

Jakob Reschke
In reply to this post by Chris Muller-3
Chris Muller <[hidden email]> schrieb am Mi., 29. Jan. 2020, 23:40:
On Wed, Jan 29, 2020 at 1:04 AM Jakob Reschke <[hidden email]> wrote:
Chris Muller <[hidden email]> schrieb am Mi., 29. Jan. 2020, 03:57:

It's important this feature does not get inherited by SaveDialog since the functionality could be harmful if used there

How so? What is bad about wittingly ignoring non-changes during save? You called it pollution yourself.

Jakob, your language is confusing because "Ignore" is the other command there that, yes, would cause them to not be committed.

But what is being added is a 'filter out unchanged methods from the list...', which, IIUC, would only remove them from the list, making them invisible, but not "Ignore" them.  So, if used on the Save dialog, would they be included in the commit?

Alright if it does not work there it should be fixed in the second iteration of course. I didn't test it. Ignoring instead of removing on save sounds reasonable, then you can change your mind later (although in this case, why would you...).

I suppose this can be covered by a unit test.


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Monticello-eem.709.mcz

Jakob Reschke
From the other thread:

Eliot Miranda <[hidden email]> schrieb am Fr., 31. Jan. 2020, 14:26:
 


On Jan 31, 2020, at 12:08 AM, Jakob Reschke <[hidden email]> wrote:


Sounds as if Pharo had dropped the timestamps from the Monticello model completely. Or all reading and writing of them.

That’s indeed what they have done.  It’s easily worked around, as my modification to Monticello shows.

Under these circumstances, maybe it even makes sense to ignore and exclude non-changes without timestamps by default.




Guillermo Polito <[hidden email]> schrieb am Mo., 27. Jan. 2020, 14:00:

Inspecting the mcz, I see the timestamps were gone, sorry.
Still, I think the problem is deeper than git/not git. Because when doing the patch I carefully loaded latest VMMaker.oscog version.
I supposed that forcing loading in monticello would reload everything. I (wrongly) guessed it should have installed timestamps too.
Then I applied my change from there.

Even just now, I got a latest fresh pharo9,
 - downloaded latest VMMaker from source.squeak.org
 - made a diff and a merge with the version I generated in the inbox
    => both empty => I cannot see problems related to missing timestamps in the UI :/
And no git was involved *at all* here.

I was maybe supposed to see changes in timestamps here? Does MC diff show that at all?
Now that I think about it, I don’t have any memories of it. But that could have helped me spot the problem before.
Maybe I could patch MC diff in Pharo to take timestamps into account?

Jakob Reschke <[hidden email]> schrieb am Do., 30. Jan. 2020, 07:48:
Chris Muller <[hidden email]> schrieb am Mi., 29. Jan. 2020, 23:40:
On Wed, Jan 29, 2020 at 1:04 AM Jakob Reschke <[hidden email]> wrote:
Chris Muller <[hidden email]> schrieb am Mi., 29. Jan. 2020, 03:57:

It's important this feature does not get inherited by SaveDialog since the functionality could be harmful if used there

How so? What is bad about wittingly ignoring non-changes during save? You called it pollution yourself.

Jakob, your language is confusing because "Ignore" is the other command there that, yes, would cause them to not be committed.

But what is being added is a 'filter out unchanged methods from the list...', which, IIUC, would only remove them from the list, making them invisible, but not "Ignore" them.  So, if used on the Save dialog, would they be included in the commit?

Alright if it does not work there it should be fixed in the second iteration of course. I didn't test it. Ignoring instead of removing on save sounds reasonable, then you can change your mind later (although in this case, why would you...).

I suppose this can be covered by a unit test.