There is some timing related issue in the synchronization logic that causes a revision to be generated on the target side before the existing library revisions have been transferred
There is something wrong with the revision history of the library
There is something wrong with the algorithm that is responsible for selecting the library revisions to merge during the synchronization
If you have the possibility to send me a log file (%TEMP%/aspect-log.sdl) of a run where that error occurs, that should hopefully make it clear what is roughly going on here.
If the library so far hasn’t been cloned (only one device), you could delete the contents of the .revs folder while Aspect is not running to likely sidestep the issue, but of course it would be valuable to keep the revisions in case they are needed for further debugging. However, if the library is already cloned to another device, deleting the revisions would mean that further synchronization would be not possible anymore, so this is definitely not generally advisable!
I’ve tried once more and shared the .sdl file with you over email.
Please let me know if for the next step you want me to try to delete the .revs folder, as you have mentioned. As of now, the application is not synced with other devices (so there should be no risk of breaking synchronization with other devices).
Thank you! I was able to pinpoint the issue to a change introduced by 1.0.0-preview.40. The change is meant to improve usability for libraries that span multiple drives, but has caused library maintenance tasks to be executed on a library that is still in the process of being cloned. In this case, this caused a revision to be created in the cloned library before the existing revisions could be fully synchronized, resulting in a conflict.
Please let me know if for the next step you want me to try to delete the .revs folder, as you have mentioned. As of now, the application is not synced with other devices (so there should be no risk of breaking synchronization with other devices).
You can delete the revisions now to get the clone to work - the log file has been sufficient for finding the issue. If this is not so urgent, you could also wait for the next release (should be this Friday) to verify that the issue has been fixed for your particular situation.
We missed that issue in testing yesterday, but it has been caused by the change to drop revisions older than 90 days. I’ve uploaded a quick new version (1.0.0-rc.18.1) that has this fixed.
Okay, while continued to test this, I have discovered another issue that manifests in a “missing revision” error when loading the newly cloned library instance. I’ll unfortunately have to make another release after this has also been fixed.
