Some files are *always* conflicted

thany commented 1 month ago

Abstract

I have a few files that, after syncing (and syncing happens to work), are always in a conflicted state. These are files that no longer exist.

When a popup appears telling me about it, I click it and a dropdown appears that allows me to select which conflict to resolve (this only works on desktop btw - something to think about). When I then select one of the files, for a second or two, nothing happens, and the same dropdown appears again, with the same files. Ergo, nothing has been done, conflicts are still there, and there is no way to resolve them.

Expected behaviour

If there are conflicts, make sure they are actually conflicts. Deleted files are not conflicts. They are just deletions and can be synced, even without user intervention.
If there are conflicts that require user intervention, present a UI that allows the user to actually amend the conflict and carry on. The result of a conflict should always be something, anything, that brings it to a resolution.

Actually happened

Files are needlessly put into a conflicted state, it appears
No UI is presented at all to resolve a conflict (even though these aren't conflicts to begin with) which means any conflict will remain forever unresolved.

Reproducing procedure

No idea how. I guess delete a file somewhere at some point. This just started happening out of nowhere.

Report materials

Sorry, I can't do it at the moment, because of my other issue. When that one is resolved, I can attach things that might help. But the important thing here, is the UI around conflicts, which is basically non-extistent. My current take is there isn't an issue that is specific to my setup.

thany commented 1 month ago

Update: I now also seem to have files that don't get synced. Yesterday I performed a successful sync, which should've uploaded documents that I newly created, and not, syncing on a different computer, they're still missing.

I'm sorry to say, but this makes me feel like Livesync is just unreliable. It makes me want to verify that syncing has actually been done, instead of poping up a million messages about sync, and then effectively having done nothing from a user's point of view.

Edit:

I've just now literally pressed sync on computer A, where a new file had been added. Then, after it's done, press sync on computer B, where that new file doesn't exist yet. Result: the file is NOT being synced.

This is ridiculous. Am I really going to have to, what, manually copy it over? I'm starting to understand what the person in that other issue was all about. It's way too complicated and/or unreliable. I can even see it in the couchdb database. It's right there. Why isn't it downloading it?

The log just says "yup, I'm done" - No you're not!

Edit 2:

It gets worse.

I just made a small change to the file on computer A and then synced it. Then on computer B, not only does it still refuse to sync (just bloody download) it, but it thinks it's a delete?! Like actually wtf?

08/10/2024, 11:07:14->Processing redacted.md (Vakantie: 4-ab3) :Started...
08/10/2024, 11:07:14->delete skipped: redacted.md :Already not exist on storage
08/10/2024, 11:07:14->Processing redacted.md (Vakantie :4-ab3) : Done

First of all, no it's NOT done, it's still missing. Secondly, why is it trying to delete it? It doesn't exist on storage, no that's why it should be CREATED, not deleted. What the hell is going on.

Edit 3:

The other war round also doesn't work.

Seriously, I don't know what the hell this tool is doing, or pretending to do, but it's completely knackered. I might as well not use it.

vrtmrz commented 1 month ago

Thank you for opening the issue!

I guess the situation as the conflicted revisions of a file exist in many numbers. The resolving dialogue will be open multiple times. But probably we have not realised that they are different asking. (Actually, there are no revisions displayed). If we give up the dialogue once, that will not be displayed until the next boot, or performing Resolve if conflicted' orPick a file to ...`.

And even worse, the conflict will be transferred among the devices. So if we do not resolve this completely, we will get data with conflicted revisions -- i.e., already conflicteds, and modifications as a new conflicted revision. That seems to us as mysterious behaviour. (And possibly, in this case, the main revision might be a deleted one).

Fortunately, I have already addressed it from two sides.

Completely rewriting these logics (I also know the side-effects, usually suffer).
Writing documentation about the total how-to of that (it contains the details of handling conflicts).

So, please let me spend a bit more to make the new version more reliable. And if you have completely got stuck and been very troubled, please disable customisation, use presets, and rebuild both databases once.

thany commented 1 month ago

Yeah, in the mean time, I think I'll switch to Git.

Livesync appear to attempt to rewrite version control in a backing system (couchdb) that totally doesn't have that. Reinventing a square wheel on a vehicle that doesn't use wheels.

Git is exactly meant for this kind of stuff. And as a bonus (at least on desktops) I can manually fix things if they go haywire, just on the command line, or even using a dedicated GUI for Git. I'm not neccesarily stuck to one tool.

Something to think about: maybe couchdb wasn't the best service to choose for the scenario of syncing many small files in differing states by multiple clients.

vrtmrz commented 1 month ago

I am sorry that I cannot resolve the situation fast. But I understand that your stable environment is more important to you.

Let me make one excuse. This is what I was messing up and CouchDB actually does this better.

At v0.24.0, I have rewritten these things back as by nature.

I think It will be improved slowly but slightly. I await another opportunity for you to use it.

vrtmrz / obsidian-livesync