Sync: Merge conflict detection or handling

[bbrks]

I'm not asking for a fix for this issue, but more to start a conversation on how you think the project should handle conflicts (if at all?)

I'm quite new to Rust, but have a reasonable amount of experience with distributed document syncing, including conflict resolution, and am more than prepared to help work on this to fit my personal wiki needs!

---

When there are conflicting changes on the git remote, and on the wiki, deadwiki will push the unresolved merge conflict back up to the remote. This is preferable to losing the data on either side, but nothing in the logs or UI indicate a conflict has happened, and the rendering of a markdown file containing merge conflicts is kinda broken.

This is somewhat tricky, as changes are synced asynchronously, so the conflict isn't detected until after the user has submitted changes and sync has started. One basic approach could be to trigger a pull before saving a page, and at that point, notify the user a conflict has been detected, and ask them to resolve it manually in the markdown editor before saving again, but this adds quite a bit of overhead to saving of documents.

[xvxx]

Sorry if you ran into this! It's a rough part of the app. The whole thing is pretty much a proof-of-concept at this point, but I'm working on refactoring in the vial branch and will be merging that soon.

This is preferable to losing the data on either side, but nothing in the logs or UI indicate a conflict has happened, and the rendering of a markdown file containing merge conflicts is kinda broken.

I think in the short term, solving these issues you've identified would give the user the necessary tools to fix the conflict:

1. Show an error in the web UI when syncing fails.

2. Render the merge conflict differently than a regular wiki page and resolve it when you submit changes.

The error could be displayed wiki-wide for any errors generated while syncing, so you'd at least know something happened. Could double for showing you network issues and whatnot, too.

The conflict page could just show plaintext, or launch you right into the editor with a message printed above it.

(Of course, multi-file conflicts might be a bigger problem...)

In the longer term for merge conflicts, I've mostly been thinking about how to avoid them. At least, in common cases. Since this is a single player wiki, I've been planning to add two explicit sync points:

1. When you load a page, sync if the last sync was more than SYNC_TIME ago. The goal being you're always working with the latest version of the wiki data.

2. When you edit or create a page, sync immediately. The remote should always have the latest version, too.

The idea with these two is that the user is probably bouncing between a few different computers running deadwiki, so submit any changes as soon as they make them and pull changes as soon as they begin a new "session."

Beyond that, I was going to add the SHA to the edit <form> and compare it against the SHA when you submit, to prevent overwriting newer data.

But I am open to all ideas. I want to keep the act of creating and editing wiki pages extremely fast, so I don't want to put a git pull in the middle of that flow specifically, but I do think it makes sense to kick off a sync right away and then display an error if it failed.

[bbrks]

Sorry if you ran into this! It's a rough part of the app

Not to worry. I only encountered this because I was intentionally causing conflicts to see how it handled the situation. I've been bitten by other note taking apps that simply drop one set of changes/last writer wins.

The only situation I'd imagine I would run into conflicts in the real world would be if I have an offline locally-running wiki, and I want to make some changes to it, but upstream has since updated.
Editable offline notes are something I'd want to have, but not something I'd use super often, so being a sharp edge is entirely reasonable.
I agree that those 2 steps of improved formatting, and throwing errors back up to the UI would be more than sufficient to put the onus on the user to resolve.

[xvxx]

The offline scenario is a good one, I’ll make sure to test that out. I’m going to leave this open until it’s tackled.

[xvxx]

Okay, I've added the start of this: if your wiki page has git conflict syntax in it, you'll get dropped into the editor with a message:

I think for the second part I'll add a /conflicts page that will just grep all your pages and list any that have conflicts in them. In the future when we get more fancy we might be able to do a notification in the UI or something, but I think this will at least be better than nothing for now.