Given the naming convention, these might be old v2 backups that were created back when you upgraded to version 3 (or maybe even older if you are still on v2). If you repeatedly open the backup copy that is saved before upgrading, then you will get a perpetually growing list of duplicate backups. Naturally this is because the backup is in v2 format still, and will need to be updated each time you try to open it, which causes a backup of the backup to created, and so on. So if that’s what they are—they can probably be discarded at this point. The only purpose for these are for quick and ready recovery in case the upgrade procedure fails and produces a broken project.
That said, answering “why?” would be helpful as would any work-around that is more convenient than the one I described herein.
I don’t have the prior conversation that you are referring to handy, but I can think of a few reasons for why this would be difficult. As a disclaimer, I cannot claim to understand what comparing two projects means, at a basic conceptual level. In perhaps the most basic of projects there might be something plausibly done to compare them somehow—but what about projects with tens of thousands of items in them, and maybe gigabytes of audio/video interviews, PDFs, PowerPoint presentations, etc. How does one compare a massive archive like that?
- You’ve aptly demonstrated one problem already: what aspects of a project would different people consider to be significant, for the purposes of comparison? You’re talking about compiling the draft folder using a specific set of settings and comparing the two using one specific piece of software—but what if the important difference between these projects was a six hour keywording binge in your research folder? What if you are needing to compare ePub files because that is all you ever use Scrivener for?
- So if we are to broaden what constitutes the project, then things get a lot more complicated, very quickly. How could the software demonstrate that you’ve shuffled the order of colour labels in one of the projects, but little else? What about changes to default settings like the project’s formatting or styles? To my mind it is difficult to sweep these things aside as insignificant. One change to a metadata field could radically alter how the project compiles (again, assuming that is of relevance).
- As the need for comparing disparate and difficult to compare stuff grows, then the need for an increasingly complicated GUI is necessary:
- We would need some way to navigate through the binder tree so we could compare the names, icons and other organisational aspects.
- We would need to be able to inspect individual items with some kind of sidebar that grants access to all item metadata.
- There would need to be a Scrivener-calibre text viewer, capable of showing inline annotations, linked notation, styles, images in all of their forms, etc.
- And what kind of comparison would it be without some large-scale searching and gathering tools, like the sidebar project search and main outliner/corkboard views. Otherwise you’d have to go through each file one by one.
- Maybe you can see where this is going…
And so to that end, I can think of no other interface, no better method of comparing projects, than opening them both up side by side and using the full interface at your disposal to compare them! Anything else would be a dilution of what you can do with that setup. Anything else would be a potentially fatal simplification that omits the thing you really care to spot. I wouldn’t call this a “workaround”, I’d call that “using Scrivener”, but that’s me.
Here are some hints that can help:
- Use Project Search in both projects to find everything modified in the past month or so (search for “mdate:>30d”), and then click the little “hook” button in the search results header bar, to load the result over into the main editor. From there you can switch to Outliner mode, and sort by modification date—and now you can easily see which things have changed in both projects, perhaps even independently.
- Recovery of an item from an otherwise unwanted copy of the project can be done with drag and drop between project windows.
- Enforce upon yourself a strict routine of putting the candidate project on the right or left side of the screen (whichever makes the most sense to you), and the previously selected “best copy” on the other side. If the candidate ends up being better, then close the inferior copy and move the candidate over to the best-copy side.
- Consider temporarily disabling global backups—but if you’re good with checklists then a good one to add to the top of the list after opening a candidate project is to go into Project Settings: Backups, and disable this project. This way, as you open and close these different copies you won’t spam your backup folder, and potentially cause a valuable older version to drop off of the list of maintained backups. Of course once the final candidate is selected, the last item on your checklist should be to turn its backup settings back on.