Keeping Projects Organised
Scrivener is foremost a project oriented tool. Unlike database style software, which handles file management for you, and often only lets you have one database to work with. Scrivener lets you create and work with many projects, even at the same time. These projects are stored in your user folder (usually) as ordinary files and folders. On a Mac, they will look like and act like single file, but they are really just a folder with a lot of files in them. One Windows, you'll interact with the .scrivx file, but the whole folder is the project. It must move together, and be copied together when making backups.
One of the most important things that any writer can do is keep their work backed up. Scrivener offers some powerful features out of the box that will help you keep your work automatically backed up. By default, every time you close your project for the session, a backup will be created in the a special backup folder. These will be rotated out as new ones are created, to save space. In addition to this, you can still utilise tools to manually backup your projects to any location you prefer, including Internet storage devices like Dropbox and SugarSync. I definitely recommend continuing to keep your projects backed up manually, even with an automatic backup system around, as intentionally created backups in a separate location will give you further redundancy, and keep important milestones from “rolling off” the backup list if they get too old. Remember backups aren’t just for when your computer fails you, they are also for when a you realise something isn’t working out with a particular line of reasoning or narrative you took, and you’d like to go back to an earlier revision.
With all of these backups floating around, it can sometimes get a little confusing. Which project file contains the latest version of your work? Sometimes the datestamps that Scrivener helpfully places into backup names do not accurately reflect this information, because the datestamp is only added when you create the backup, and doesn’t change even when you edit it, being a part of the file name. This can get even more confusing when you are working on more than one computer and use the backup feature to transfer projects between computers.
Organising Live Projects
Here are some strategies you can use to help keep things from getting overwhelming. By "live" projects, I mean stuff you are working on or have worked on in the past, to differentiate from backups of those projects you've created.
As with all advice, you needn’t follow it all precisely, but take what you will and adopt it to your own methods. I like to keep my working projects scattered all over my home folder, organised into folders according to their kind. Projects relating to Scrivener itself might all be found in a sub-folder called “Scrivener Work”; projects for my fiction projects might be in “Working", under a sub-folder called "Writings”, projects with old journal entries in “Archive/Writings/Journal”; you get the idea. Others might like to keep all of their Scrivener projects in one location, such as “Documents/Scrivener Projects”. Many just keep everything in Documents, since that is where Scrivener starts you off by default.
No matter where you store your working projects (as opposed to the backups of those projects), you can employ a routine to help keep confusion at bay. I have three rules that I follow:
- Keep backups stored in a separate location from the working files
- If a project file doesn’t have a datestamp, then it is a working project.
- I never open a dated project unless the main working project needs to be restored from a backup
Restoring From a Backup
On that last rule, I only open the backed up projects to verify which version I want to “promote” to working, not to edit them. Here is the procedure I follow when restoring a backup:
- If it is possible to open the current working project: Open it and immediately save a manual backup, suffixing the name with “-BAD”. This way I’ll have a copy just in case, but I know from the name that I should only use it if the situation really warrants it. This helps differentiate it from ordinary backups.
- If it is not possible to open the project for whatever reason, I compress it to a zip archive, and suffix the name with “-DOUBLEPLUSBAD” using the operating system or a tool for making zip files. With files like that, I know it won’t open and if I need to get data out of it, I’m going to have to do some rooting around in the project itself.
- Now at this point I have a .zip file with the last working copy of the project in it. So I'm safe to delete the entire "bad_project.scriv" project folder. With the working project completely removed from the working areas, I go into my backup archives and locate a copy that will suffice for restoration. This is the only time I open backup files.
- As soon as I identify a candidate, I close the project; and in the Finder I make a duplicate of the project, move it to the working areas, and remove the datestamp.
Following these instructions, the topology has not changed, only the internal composition. There is still only one file on my hard drive that does not have a datestamp---the working project file---and everything else has a datestamp or a suffix.
Using This Method to Transfer Projects
These rules can be altered to accommodate a workflow where one uses the backup system to transfer files from one computer to another. If you use Scrivener Backup Project To feature to create zipped copies of your project to Dropbox, on the second computer you can use a modified set of instructions like the above to keep your drives clean and logical. If you do use this feature for transfer, you might want to keep a separate folder just for transfers, but that is up to you.
I take things a step further in transfer situations. When I start working on a new computer, I let the network sync down the latest .zip backup that was created when I closed out for the day on the other machine. I first delete the working project from that computer. I don’t need it any longer because I have a backup on the shared location. I then copy the last available zipped project (using the datestamp) out of the shared folder area, decompress it, and remove any suffix naming if necessary. On a Windows machine, you can just open the .zip file right off of your sharing area and drag the new project copy out of the .zip window. Since Macs don't ask where you wish to extract the contents of the .zip to, you need to copy the .zip to the target location, first.
Hopefully these simple tricks will help you keep your projects logical, and a retain a clear separation between transfer files, backups, and working projects. It’s a little extra work, but not too much, and in the long run it avoids the mess of having a proliferation of dated projects all over your drive, sometimes with multiple appended datestamps, and no good indication of which one you should be editing.
One final piece of advice for Windows users: like I said at the top, the whole folder that ends in ".sciv" is your project. It is a cohesive bundle of files and folders that all must stay together to work together. It is not a good idea to put auxiliary files into this folder. As tempting as it might be to put compiled versions of your manuscript or bits of research data you don't want to import into the project, it's just not a good idea to do. We take pains to keep what you put in there safe, but since whatever you put in there is by definition not expected to be there, it is categorically less safe than storing it alongside the ".scriv" folder.