Better conflict resolution with diff

On desktop I’m seeing a new-to-me window that upon sync conflict shows all the files in the project with a version date picker at the top. While this might be slightly more helpful than what I’ve previously seen (a “conflicts found” message and conflicted files placed in a folder together)—it’s not very useful for determining what has changed or which version I want.

What’s been missing from the sync conflict experience is a common “diff” interface:

  1. By default, just show the files that are conflicted. When showing all files, highlight the conflicting files so they’re easy to notice in a long list.
  2. Give the ability to open and compare the contents of each conflicted file
  3. Show comparison side by side (maybe force landscape on mobile) of both versions
  4. Make the versions scroll simultaneously
  5. By default, just show changed text
  6. Highlight everything that has been added in one color
  7. Highlight everything that has been removed in another color
  8. Give the ability to transfer individual edits from one version to another
  9. Give the ability to pick one version and remove the other

Bonus round
10. If you’d like to go beyond what is used for coding apps and make it best for prose, separate “edits” not just by line (carriage returns) but also by sentence. That way browsing through differences especially in large paragraphs won’t be as difficult.
11. In the comparison view with all text shown, also show a minimap/outline/preview of the whole file on the side so it’s easy to scroll to the conflicting edits.

(Note: I’m posting about this specifically because the other posts I found about conflicts, versioning, and comparison weren’t specifically about sync conflicts)

All the posts about versioning and comparisons also apply to sync conflicts.

If you are getting sync conflicts often enough to actually need this level of detail, you probably should look at your sync process. Sync conflicts should generally be seen as a “not normal” situation.

There are some options in the Scrivener → Settings → Sharing → Sync pane that might be helpful. Putting documents in a “Synced Documents” collection and setting the option to take snapshots would make the full functionality of the Snapshot feature available for resolving conflicts.

It would also not be a bad idea to make a backup before syncing. You’ll find that option in the Settings → Backups pane.

I get conflicts fairly regularly, going between MacOS and iOS. It’s not the majority of the time but it’s enough that it’s on my mind with every sync.

About Sync and Backup settings: I’ve already had the “Synched Documents” and “Backup on sync” options enabled for a long time. The Snapshot on sync option would be new to me.

Regarding use of Snapshots: I’ve just tried making a few test snapshots. While snapshotting on sync is good for data safety, the ability to see what is different between snapshots is again very poor. The “Compare” button is a useless toggle between the full text of snapshots. The Roll Back button’s function is unclear, even with the info shown after clicking it. Also more importantly, I don’t see any Snapshot functionality in iOS, so even this isn’t available there.

Thank you for the suggestions but they’re just not helpful, like a diff view would be.

I second this issue. I had a sync conflict due to some Dropbox client issues on one computer. Now I have a ton of sync conflicts that I’m going through. There are a few dozen there, and the first ten or so have been identical to what’s in my main manuscript. Having a built-in diff feature would be lovely.

That is in fact exactly what the Snapshot comparison tool is. On the Mac it even calls the UNIX diff tool directly, in order to get this data, and on Windows it uses a diff library.

But I think what this thread is more focused on is feedback on the user interface of that, rather than there not being anything at all. In reading the feedback, it is clear to me that the existing tools were not at all heard of prior to writing up the feedback, as much of what is requests already exists, or isn’t necessary given what does exist (for example, stripping out all of the context around the changes is not necessary, or in my opinion desirable, if you can efficiently jump from one change marking to the next with keyboard shortcuts or buttons).

To see what is available, start by checking out the user manual PDF, in §13.6.4, Comparing Changes with Main Text. This section goes over side-by-side comparison, jumping between markings, adjusting the granularity of markings and so on.

Disclaimer: the Windows version was never completed. For example one of the refinements we wanted to see in the v3 design is side-by-side comparison. This was only halfway done, in that you can load a snapshot into a split, but never with comparison markings.

The only thing it doesn’t cover in particular is how to get from an entry in the conflicts folder Scrivener creates (incidentally the scope the OP was asking for, the conflicts are all in that one date stamped folder). This section is mainly just documenting the inspector tools available—but they are good to look at first since this is the “hub” of the feature, along with the Snapshots Manager.

For some tips on specifically resolving sync conflicts, refer to §14.2.2, Avoiding and Resolving Conflicts. The end of this section cross-references to §15.8, which is the main section on Snapshots in general, and obviously worth a peruse as well.

This is a very useful feature for multiple purposes, not just figuring out what is different about a conflict copy in a bad sync—hence the comment about how all these other practical discussions about comparing text have a lot overlap with sync comparison. Having this thread out all by itself, not benefiting from those discussions, is a bit unfortunate as it might lead one to believe Scrivener is entirely bereft of any toolset for tracking revisions, version, collaboration updates, workflow merges, conflict resolutions, or the many other things that might cause text to change over time.

We improved the feature quite a lot in v3 (for example, split view comparisons). We might not add much in the future as we already have a lot of the right ingredients in my opinion, but I do think we should pay attention to making the tools that are there a bit more cohesive and easy to discover. Right now you have to be pretty confident with the lesser used corners of the software, and know enough to perform problem solving (snapshots have compare, to compare two texts take a snapshot and paste the updated text into the main editor, then click compare), which leads to feature requests like this that ask for stuff, 85% of which already exists. So, we can and should make that easier to figure out.

1 Like

Interesting fact but that doesn’t mean the sync conflict resolution experience isn’t poor.

This thread is separate because it’s specifically about resolving sync conflicts, which are not addressed in those other threads and so those threads have little to no relevance here. Threads are to discuss issues, not provide PR for your product.

While I’m sure the issue I’ve raised and constructive directions I’ve suggested would benefit the other reasons for using version comparison—my primary concern is resolving sync errors with less time and inconvenience. That’s the only place I’ve really needed it, further encapsulating the need for this separate thread.

Writing out many paragraphs about the tool documentation but 1) not addressing that this situation does fall through the cracks and 2) implying that functionality doesn’t need to be improved is not helpful. In my opinion that is not good customer service.

I’ve explored those corners with plenty of confidence and found them lacking. Look at what’s available for sync conflicts and the Snapshot Manager. Then look at for example, the Visual Studio Code compare experience with or without a merge conflict. The differences between all three for resolving differences are stark and impactful. The start of my thread still stands.

This last sentence is the only one that gives me any hope. It’s also the only response I feel like you needed to give here.

I was responding to someone else, not you.

I’ll that keep in mind, for you. :laughing: