I just updated to Scriv 3 on a new laptop (2 wasn’t installed, though it was used heavily on my previous laptop of last week). I also use the app on my iPad. When opening my project it 'resolved 'hundreds (at least 350) of conflicts, and plopped a whole bunch of files in a ‘Recovered Files’ folder.
I’m having a hard time understanding the process.
The file ‘titles’ and metadata are nondescript, meaning they are all timestamped with todays date, and either list ‘conflict’ or ‘notes’ in the file title with a seemingly non-sequential number in the title as well. Many, most listed as notes, seem to be just an old document (scrivening) title, with no other content. Many more are actual pieces of work (poems or general writing snippets), some old revisions, some duplicates. I can’t really tell if these are duplicates or missing files, or alternate versions in relation to my regular (non-recovered) project files.
I’m sure that’s not very well described, but perhaps just some insight into what is considered a conflict, etc. might be helpful for me.
That looks to be the result of the newer and more robust mechanism for recovery data from third-party sync conflcit files. For example if a project is synced on Dropbox and you accidentally edit it in two different places without syncing first, then when Dropbox finally gets a chance to compare the two project folders, it creates duplicate copies of the files that were conflicted. In the past these would have been forever obscured from you unless you went into the project package and poked around. Now we are repair them into the binder so you can take a look and make sure you didn’t lose any edits in them.
Since all manner of things can trigger a conflict, they may not always be useful however.
Is there any way to tell which of the original / existing files the conflicted files conflict with? I have 100 in a project that I believe was fine until I opened it with Scrivener 3. Looking at the package contents directly, I haven’t been able to locate the files. I really don’t want to check 100 files manually without knowing the filenames at the very least…
If you want to get a better picture of things, I’d examine the package contents from before updating. The recovery process will remove the original orphaned file and convert it into a proper binder item. At that point it will look like all other binder items from the context of what you see in Finder.
So to see what was there, what necessitated a recovery, you’d need to go back to a version of the project prior to recovery. Likely you’ll find a bunch of “23 (conflicted copy blah blah).rtf” type entries. Managing the conflicts by hand using the file system is the old way of doing this, and it still works and for those inclined to do so there may be some advantages.
Thanks - that was really helpful. I was able to narrow it down from 100 to 2 that needed to be checked.
But I wonder if there wouldn’t be some way in the Scrivener 3 conversion / conflict management process to preserve the info (i.e. the corresponding numbered filename from the Scrivener 2 project) such that digging around in package contents from the backup copy isn’t necessary.
Or at the very least, document it better. Searching the Scrivener 3 manual for conflicts led me to scrivener.tenderapp.com/help/kb … g-problems which wasn’t nearly as helpful as your post.
It’s a tricky thing to document since the nature of the problem is, in a certain light, damage. Some external program has messed with the internal structure of the project and broken it in some way that might be very specific to how that system works. We don’t tend to think of it these terms because the manner in which these systems do that is usually benign—duplicate files etc.—but it’s still unpredictable and ultimately a process of documenting another company’s synchronisation conflict protocols.
As to more intelligently handling these—I think you will find in v3 that this is smoother going forward. You’re talking about conflicts that were generated in an old v2 project that are now finally being rescued in v3. The new internal format structure should alleviate some of the ambiguity that existed in the older version. Much of the impetus behind the new project design was in fact to increase robustness against sync damage of all kinds. When the old project format was invented, people used the word “dropbox” to mean where you put your hotel keys when you check out.
Would be really great if someone at Scrivener was to make a tutorial video demonstrating the “resolve conflict” functionality and best practice techniques for both proactively avoiding, and if not avoided, fixing “resolve conflict” issues when they appear.
Best practice for avoiding conflicts is very simple:
Before you launch a project, make sure that the device is fully synchronized with whatever service you are using.
When you are done working with a project, before you put the device down, make sure it is fully synchronized with whatever service you are using.
2a. Close projects when you are done with them.
If in doubt, synchronize. That is, if you aren’t sure whether the local version of a project is “current” with your synchronization server, synchronize it.
