Improvements in simultaneous (concurrent) operation

[maidis]

Currently, when one user opens a page to edit it and another user also edits and saves that page, the changes made by the second user are deleted when the first user saves their changes.

I don't know how other Wiki projects handle this issue, but it would be great if different users' non-conflicting changes on a same page could be saved without causing data loss.

Revision 4 was deleted because I opened the same page to edit it earlier and saved it later.

[eMukator]

I see two solutions. The first is to create a temporary lock on the page when the first user starts editing, and release the lock after saving or the user session expires. The second is to create a CRC when editing starts, compare before saving, and if the CRC does not match, display a "merge form" to implement the changes. The first option is by far the easiest to implement.

[maidis]

Both are useful for our situation. But the second one would definitely be a greater achievement for both the project and us.

[NTDLS]

Something like this? https://github.com/user-attachments/assets/4cb0bf90-de6f-4308-aa6f-98ceb13ca123

Also, I do not like the terminology "new" and "old". Should we also allow the user to select both old and new? If so, we need to also allow them to specify the order of the chunks in the merged version.

I'm also thinking that this should post to a "review page" so the user can preview the merge.

[NTDLS]

I see two solutions. The first is to create a temporary lock on the page when the first user starts editing, and release the lock after saving or the user session expires. The second is to create a CRC when editing starts, compare before saving, and if the CRC does not match, display a "merge form" to implement the changes. The first option is by far the easiest to implement.

Really thought about the temp lock, but I do not know of a reliable way to release a lock in the aspnet session lifecycle.
I like the CRC option, but when I reviewed the schema it dawned on me - we have a revision number.... Well, now that I've typed this I'm thinking you might be right. No need to display a merge if the new revision is the same content as the user is submitting.

[NTDLS]

@emo333 you want to jump in here too? This looks like a fun issue.

[eMukator]

I see two solutions. The first is to create a temporary lock on the page when the first user starts editing, and release the lock after saving or the user session expires. The second is to create a CRC when editing starts, compare before saving, and if the CRC does not match, display a "merge form" to implement the changes. The first option is by far the easiest to implement.

Really thought about the temp lock, but I do not know of a reliable way to release a lock in the aspnet session lifecycle. I like the CRC option, but when I reviewed the schema it dawned on me - we have a revision number.... Well, now that I've typed this I'm thinking you might be right. No need to display a merge if the new revision is the same content as the user is submitting.

Let's try to keep it simple. I suggest using a temporary lock and checking that the user is editing bind to a websocket connection. We can use SignalR, possibly SSE, or rewrite the editor directly in Blazor.
With SignalR we can go even further and not need a lock at all. When the server tries to save, it asks all active clients if they are also editing, and if so, it lets them know that a change has been made, and possibly forces the changed lines to them - but this will require some exploration.