What files can be ignored if you are using git to backup a project

Scrivener
, ,
1

What files can be ignored? It seems like I get file changes just from opening Scrivener.

2

We do not recommend using git (or any other version control system) for Scrivener projects. Unlike, say, application source code, Scrivener projects are RTF files, not plain text, which means that they contain formatting commands that are not readily human-reviewable.

A complete Scrivener project includes the entire contents of the .scriv package. There are no “extraneous” files.

3

It’s the only solution to what I need, I need the entire project to have a version history that includes chapter and scene ordering. Snapshots do not perform that functionality.

4

Have you considered using Scrivener’s built in Back Up To feature to make point-in-time versioned zipped backups of the project?

It’s not fancy, but it certainly works.

Best,
Jim

1 Like
5

I think there’s just the lock file that indicates that the project is open. I wouldn’t add it, though I’d be careful to only commit changes when the project has been closed. Do keep in mind that emptying the trash (and possibly other actions?) will actually delete OS files and folders within the Scrivener project folder, so you’ll need a handy way of removing the files that Scrivener deletes.

Or, you could compile an outline of your draft folder to PDF and re-import that into your project, which will preserver the binder order without messing with GIT. It’ll also get/keep you in practice using the compile feature.

6

I wouldn’t go so far as to say one should not use version control on a Scrivener project. It is fundamentally compatible with the basic technology—where things get contentious is in how that technology is used. We’ve had a number of discussions on this topic over the years, but most of it can be summarised into the following:

  • Don’t use it like you would manage a code project with multiple people working on it. That will be very messy and honestly not worth the effort. There are better built-in tools for merging multiple concurrent edits.

  • So what can work is if you use it almost more like an incremental backup system where only one user is working with the repository (I suppose multiple parties could, but you’d have to be as careful about working that way as you would with Dropbox or similar—you can’t all be working on it at the same time).

    It sounds like this is entirely your intention, and so I would say you’re in the green as far as that goes. And for that, we have seen a number of people over the years using it safely—I myself have used it in that capacity safely.

Now I no longer do, but not for any reason other than preference. I decided that using something better for that very narrow purpose, like an incremental rsync setup using hard links, was just as good for what I wanted. I didn’t see much material advantage from using something more complicated, but perhaps there is something to be said for familiarity and a larger pool of helper tools in the git ecosystem.

Yes, it is true that Scrivener’s automatic backups can give you an incremental history of the evolution of a project—but a 500mb project will require ~12.5gb to store a month of history if you work on it nearly every day. If one is technically inclined toward better more efficient solutions, then go for it.

Now for what can be safely ignored:

  • The ./QuickLook folder: generates a dynamic preview on macOS, is rebuilt when the project is opened and closed, and is merely a duplication of core data. You won’t ever see this unless the Mac version works with the project.
  • ./Files/search.indexes: if missing, will be rebuilt automatically on load. It has no exclusive content within it. Not versioning it will mean a slow initial load if the project is restored, but it’s no big deal. This is what every iOS user does whenever they sync, anyway.
  • ./Files/user.lock: only present while the project is opened, which is an impossible state when stored in a repository. Ideally it should never be uploaded as the project shouldn’t be mirrored while open (minor configuration data loss—such as UI settings—could occur from that practice), but it’s safe to ignore it.
  • ./Files/binder.autosave: a binary (zipped) copy of the .scrivx updated on every auto-save tick. Not necessary to version control this, particularly if you have secondary backups (and you definitely should).
  • ./Files/binder.backup: as above, only updated when the project is successfully opened.
  • ./Settings/recents.txt: maintained for the iOS version, which has a much simpler history function. If you don’t use iOS, or can do without the Recents binder list being populated on backup restore, that’s a rather “chatty” file that can be omitted.
  • ./Settings/favorites.xml: Convenience data; a record of frequently used targets for the Documents â–¸ Move To â–¸ submenu. If you move stuff a lot with that command, this file will frequently change and result in version clutter.

Beyond that there are some grey area things you could probably omit depending upon your tolerance for losing settings. The ui.ini, ui-common.xml and ui.plist files all store window state information as well as project display settings. If missing they will be repaired to a factory state. I wouldn’t want to lose that stuff unless I ran into a bug with them, but they are the sort of thing that you’ll see updates to almost every time you open a project since they record what you viewed last and so on. So it would be annoying to lose your settings, but it wouldn’t damage the project to not have them.

3 Likes