I saved Multilingual-lrnp.283 successfully, but the connection timed out during #sendNotificationsForVersion: so something didn't register as having happened.
When asked, there are no changes for Multilingual, but Monticello will open a Save New Version window... it just won't have anything at all except the name and description template.
The package list even says it's on version lrnp.283, but some dependency somewhere never got the memo so now I can save no-change versions.
Hi Lauren,
I assume that your version was saved in the package cache directory, which you can find in the list of repositories along with the remote repositories.
If you find it there, you could use the "Copy" button to copy the version to another repository, such as the inbox. This effectively tries again to upload it.
Or is the version listed in the remote repository but corrupt there?
Kind regards, Jakob
Lauren Pullen drurowin@gmail.com schrieb am Fr., 29. Apr. 2022, 07:36:
I saved Multilingual-lrnp.283 successfully, but the connection timed out during #sendNotificationsForVersion: so something didn't register as having happened.
When asked, there are no changes for Multilingual, but Monticello will open a Save New Version window... it just won't have anything at all except the name and description template.
The package list even says it's on version lrnp.283, but some dependency somewhere never got the memo so now I can save no-change versions.
Hi Jakob,
On 4/29/22 06:29, Jakob Reschke wrote:
Hi Lauren,
I assume that your version was saved in the package cache directory, which you can find in the list of repositories along with the remote repositories.
If you find it there, you could use the "Copy" button to copy the version to another repository, such as the inbox. This effectively tries again to upload it.
Or is the version listed in the remote repository but corrupt there?
Actually, I think there might be a design bug. Nothing is corrupt. I just never noticed this happens before.
Are you supposed to be able to Save a working copy that has no changes? Like, when you ask the package for changes when there are none it says 'no changes' instead of bringing up a changes window with an empty list.
Hi Lauren,
Technically it is possible to create new versions that do not introduce any changes. I do not know whether this is by design or not. It is certainly not necessary to prevent it.
Is your design bug inquiry only about the asymmetry between "Changes" and "Save", where the former has a special case for "no changes", but the latter does not have it? Or did you expect something else to be different or behave differently as well?
Kind regards, Jakob
Am Sa., 30. Apr. 2022 um 04:38 Uhr schrieb Lauren Pullen drurowin@gmail.com:
Hi Jakob,
On 4/29/22 06:29, Jakob Reschke wrote:
Hi Lauren,
I assume that your version was saved in the package cache directory, which you can find in the list of repositories along with the remote repositories.
If you find it there, you could use the "Copy" button to copy the version to another repository, such as the inbox. This effectively tries again to upload it.
Or is the version listed in the remote repository but corrupt there?
Actually, I think there might be a design bug. Nothing is corrupt. I just never noticed this happens before.
Are you supposed to be able to Save a working copy that has no changes? Like, when you ask the package for changes when there are none it says 'no changes' instead of bringing up a changes window with an empty list.
Hi Jakob,
On 4/30/22 15:35, Jakob Reschke wrote:
Technically it is possible to create new versions that do not introduce any changes. I do not know whether this is by design or not. It is certainly not necessary to prevent it.
Is your design bug inquiry only about the asymmetry between "Changes" and "Save", where the former has a special case for "no changes", but the latter does not have it? Or did you expect something else to be different or behave differently as well?
It's the asymmetry between Changes and Save. My experience with version control software is that you cannot store a commit that makes no change... why would you?
It does no harm, but it certainly was surprising. ;)
Agreed, there is no real use case where you would want to create such versions manually. Git prohibits it as well, unless you specify --allow-empty when committing.
Detecting the situation in Monticello and adding a guard would be easy I suppose, but I would not make it a priority. The handling makes the implementation more complicated (how to signal, how to handle, in a GUI workflow vs. a scripted workflow, ...) and the benefit is minimal, since one can clearly see by oneself that there are no changes in the save dialog. :-)
Also note that even if you have changes, you can "ignore" all of them in the save dialog, so we would also have to check again after the save dialog was accepted.
Am So., 1. Mai 2022 um 21:09 Uhr schrieb Lauren Pullen drurowin@gmail.com:
Hi Jakob,
On 4/30/22 15:35, Jakob Reschke wrote:
Technically it is possible to create new versions that do not introduce any changes. I do not know whether this is by design or not. It is certainly not necessary to prevent it.
Is your design bug inquiry only about the asymmetry between "Changes" and "Save", where the former has a special case for "no changes", but the latter does not have it? Or did you expect something else to be different or behave differently as well?
It's the asymmetry between Changes and Save. My experience with version control software is that you cannot store a commit that makes no change... why would you?
It does no harm, but it certainly was surprising. ;)
The philosophy of Monticello's design was to be resilient in decentralized and partial repositories (e.g., which may or may not have all version files, even though they should). It assumes less of a "centralized control" philosophy than other kinds of repositories, and therefore may be more lax in letting the users decide what content to put into their repositories. But it can at least warn you. I introduced MCEmptyVersion a few years ago to enable the ability to intercept this condition, but it's just a Warning.
An empty changes list without any message would be less user-friendly than the alert message, but when the user clicks "Save", the philosophy's answer to "Why would you," (want to save an empty mcz) is to let the human user decide.
- Chris
On Sun, May 1, 2022 at 2:36 PM Jakob Reschke jakres+squeak@gmail.com wrote:
Agreed, there is no real use case where you would want to create such versions manually. Git prohibits it as well, unless you specify --allow-empty when committing.
Detecting the situation in Monticello and adding a guard would be easy I suppose, but I would not make it a priority. The handling makes the implementation more complicated (how to signal, how to handle, in a GUI workflow vs. a scripted workflow, ...) and the benefit is minimal, since one can clearly see by oneself that there are no changes in the save dialog. :-)
Also note that even if you have changes, you can "ignore" all of them in the save dialog, so we would also have to check again after the save dialog was accepted.
Am So., 1. Mai 2022 um 21:09 Uhr schrieb Lauren Pullen <drurowin@gmail.com
:
Hi Jakob,
On 4/30/22 15:35, Jakob Reschke wrote:
Technically it is possible to create new versions that do not introduce any changes. I do not know whether this is by design or not. It is certainly not necessary to prevent it.
Is your design bug inquiry only about the asymmetry between "Changes" and "Save", where the former has a special case for "no changes", but the latter does not have it? Or did you expect something else to be different or behave differently as well?
It's the asymmetry between Changes and Save. My experience with version control software is that you cannot store a commit that makes no change... why would you?
It does no harm, but it certainly was surprising. ;)
Also note that an empty diff might happen if one commit adds sth. and another one removes it and there are not checkpoints in between. The "Squeak update" feature downloads .mcd (i.e., diffs) from the server to speed things up.
Best, Marcel Am 02.05.2022 03:24:44 schrieb Chris Muller asqueaker@gmail.com: The philosophy of Monticello's design was to be resilient in decentralized and partial repositories (e.g., which may or may not have all version files, even though they should). It assumes less of a "centralized control" philosophy than other kinds of repositories, and therefore may be more lax in letting the users decide what content to put into their repositories. But it can at least warn you. I introduced MCEmptyVersion a few years ago to enable the ability to intercept this condition, but it's just a Warning.
An empty changes list without any message would be less user-friendly than the alert message, but when the user clicks "Save", the philosophy's answer to "Why would you," (want to save an empty mcz) is to let the human user decide.
- Chris
On Sun, May 1, 2022 at 2:36 PM Jakob Reschke <jakres+squeak@gmail.com [mailto:jakres%2Bsqueak@gmail.com]> wrote:
Agreed, there is no real use case where you would want to create such versions manually. Git prohibits it as well, unless you specify --allow-empty when committing.
Detecting the situation in Monticello and adding a guard would be easy I suppose, but I would not make it a priority. The handling makes the implementation more complicated (how to signal, how to handle, in a GUI workflow vs. a scripted workflow, ...) and the benefit is minimal, since one can clearly see by oneself that there are no changes in the save dialog. :-)
Also note that even if you have changes, you can "ignore" all of them in the save dialog, so we would also have to check again after the save dialog was accepted.
Am So., 1. Mai 2022 um 21:09 Uhr schrieb Lauren Pullen <drurowin@gmail.com [mailto:drurowin@gmail.com]>:
Hi Jakob,
On 4/30/22 15:35, Jakob Reschke wrote:
Technically it is possible to create new versions that do not introduce any changes. I do not know whether this is by design or not. It is certainly not necessary to prevent it.
Is your design bug inquiry only about the asymmetry between "Changes" and "Save", where the former has a special case for "no changes", but the latter does not have it? Or did you expect something else to be different or behave differently as well?
It's the asymmetry between Changes and Save. My experience with version control software is that you cannot store a commit that makes no change... why would you?
It does no harm, but it certainly was surprising. ;)
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Jakob Reschke -
Lauren Pullen -
Marcel Taeumel