Warn about conflicts when saving scores online

[shoogle]

When the user attempts to update an existing online score, we should check for conflicts and display an appropriate warning if any such conflicts are found.

Method to update online score	Dialog to show if conflicts are found
Press Ctrl+S in a cloud score.
Click "Publish" button inside the File > Publish to MuseScore.com dialog.

See Addendum (April 2023) in the Figma design (thanks @bkunda!).

Button	Action
Replace	The online score is updated to reflect the local version (i.e. changes are overwritten).
Save as...	Equivalent to File > Save as.... A new score may be created in the cloud or on the user's computer.
Publish as new score	The score is immediately uploaded as a new online score with the title and visibility that were specified in the Publish to MuseScore.com dialog prior to the "Publish" button being pressed. (This may result in two scores with identical names on the user's online account.) The user's web browser opens at the online Score Edit page where the user can change the title and visibility if they wish.
Cancel	The dialog is dismissed without uploading the score or saving it locally.

Problem to be solved

Conflicts occur when the user attempts to edit or save a local score when there is a newer version of the score available online. This usually happens because the online score was updated from another device.

1. On device 1, create a score and save it online using either of these methods:
   • File > Save to cloud.
   • File > Publish to MuseScore.com.
2. On device 2, visit MuseScore.com, download the score, edit it in MuseScore, then re-upload via either of these methods:
   • File > Publish to MuseScore.com.
   • MuseScore.com upload page.
3. Back on device 1, open the score you originally created.
   • It will not contain the edit you made in step 2.
   • If you edit or save now, the local score will conflict with the online version.
4. Re-upload from device 1 using either of these methods:
   • Ctrl+S (only if you used File > Save to cloud in step 1).
   • File > Publish to MuseScore.com (works regardless of method used in step 1).

The edit made in step 2 is lost.

Note: you don't actually need to use a second device in step 2 as long as you edit a different local copy of the score.

Prior art

No response

Additional context

When updating an online file, conflict detection must be carried out on the server side.

Whenever a score is successfully saved or published to the website, the following information must be stored in the local file to facilitate future conflict detection:

• Source: the URL of the online score, as returned by the website (we already have this).
• Source revision: the revision ID of the updated online score, as returned by the website.

Next time the user attempts to update the online score, the stored revision ID must be sent in the request. The website will respond with 409 Edit conflict if a revision ID is sent that doesn't match the current online revision ID.

[cbjeukendrup]

@shoogle I have some questions:

Am I understanding correctly that the flow is like the following:

1. User saves score to cloud that has never been saved to cloud before. This score contains no source URL nor revision number.
2. To upload this score, the app sends a HTTP request to the website, containing the score data. The app receives the new source URL back as part of the HTTP response. After we implement this task, it will additionally receive a kind of revision ID.
   Questions:
   • What does this ID look like? Is it an integer that is incremented on every upload? Or a random integer? Or a 128-bit UUID?
   • I assume we will receive this revision ID just like "sourceUrl" in the JSON HTTP response, but under which key?
3. The app stores this ID inside the mscx file as a meta tag, just like the source URL. (Potential danger: if we don't watch out, the user can see and modify this in the Project Properties dialog.)
4. Next time the user saves the score, we simply upload it again; the website will see the revision ID inside the score file, and will compare it with the revision ID that the website generated the previous time we uploaded the score (the website has saved this ID into its version of the score file):
   • if it matches, everything is fine
   • if it doesn't match, someone else has earlier uploaded other changes and the website disallows the upload
5. If it's fine, the upload will proceed; when ready, the website will respond with a new revision ID, which we will store in the score, to be used for the next upload.

But what will happen in the following situation:

1. We successfully upload the score (and as part of that, save the changes locally, albeit with the old revision ID)
2. There is no conflict, so the website goes ahead and processes the score
3. MuseScore crashes or the connection is lost
4. The website sends back the new revision ID, but the app doesn't receive it because of 3.

In that situation, the website will use the new ID from that moment on, but the app will still continue to use the old ID, even though the local version of the file and the version on the website are otherwise identical. Next time that the user opens this file from their local cache, and tries to save it again, this will be detected as a conflict, even though it isn't.
I think the solution would be to make sure that the website should only process the upload if it is sure that the app has successfully received the new ID. Is that possible to achieve? From what I know about HTTP and TCP, I'd think that should be possible, but I'm not sure. I guess that would be mostly something for the website folks to care about; sending the acknowledgment that we have received it, will happen "for free" as part of the TCP protocol, right?

One more question that is not very relevant but I'm just curious:

• what will the website do with scores uploaded from MS4.0.x, which don't contain a revision ID even though the scores are replacing some existing score?