<div dir="ltr"><div dir="ltr">On Wed, Jan 29, 2020 at 1:04 AM Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de" target="_blank">forums.jakob@resfarm.de</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"><div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Chris Muller <<a href="mailto:asqueaker@gmail.com" rel="noreferrer" target="_blank">asqueaker@gmail.com</a>> schrieb am Mi., 29. Jan. 2020, 03:57:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>It's important this feature does not get inherited by SaveDialog since the functionality could be harmful if used there</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">How so? What is bad about wittingly ignoring non-changes during save? You called it pollution yourself.</div></div></blockquote><div><br></div><div>Jakob, your language is confusing because "Ignore" is the other command there that, yes, would cause them to not be committed.</div><div><br></div><div>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?</div><div><br></div><div>If so, then for that reason, IMO, it should somehow be restricted to general OperationsBrowser (i.e., as when clicking on the Changes button).</div><div><br></div><div>I tried installing it and looking for the menu additions, but coudln't find them I only had few minutes...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto"><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"><div dir="ltr"><div>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></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Kind regards,</div><div dir="auto">Jakob</div></div>
<br>
</blockquote></div></div>