Previously, a resolved current location (e.g. '/Users/me/myfolder' asFileReference) was compared to a possibly unresolved new location (e.g. FileLocator home / 'myfolder'), so even if the current and new location was the same FileLocation, a migration would be done.
I first thought to fix it by sending asFileReference to the incoming directory, but then realized that resolving both wouldn't work, because changing from a hardcoded location to a dynamic one that just happens to currently point to the same place seems to be a valid operation as well. For example, it would prevent users from changing the directory from '/Users/me/myfolder' asFileReference to FileLocator home / 'myfolder', because '/Users/me/myfolder' asFileReference = (FileLocator home / 'myfolder') asFilereference.
The safest course seems to be to trust the user that they mean "set it to this exactly" and not "set it to something somehow equivalent to this" by instead removing asFileReference from the lhs.
demarey
commented
4 years ago
Previously, a resolved current location (e.g. '/Users/me/myfolder' asFileReference) was compared to a possibly unresolved new location (e.g. FileLocator home / 'myfolder'), so even if the current and new location was the same FileLocation, a migration would be done.
I first thought to fix it by sending
asFileReferenceto the incoming directory, but then realized that resolving both wouldn't work, because changing from a hardcoded location to a dynamic one that just happens to currently point to the same place seems to be a valid operation as well. For example, it would prevent users from changing the directory from'/Users/me/myfolder' asFileReferencetoFileLocator home / 'myfolder', because'/Users/me/myfolder' asFileReference = (FileLocator home / 'myfolder') asFilereference.The safest course seems to be to trust the user that they mean "set it to this exactly" and not "set it to something somehow equivalent to this" by instead removing
asFileReferencefrom the lhs.