I use Tortoise SVN to back up and version all my work projects (web developer), and I’d like to do the same for my Scrivener files as well. But I’m concerned about how Scrivener might deal with the ‘.svn’ subfolders that will be created in the various ‘myproject.scriv’ folders. The last thing I want to do is corrupt the Scrivener folder structure, or what Scrivener is looking for when it accesses the project folder.
Am I worrying about nothing? Or should I perhaps only include some of the project folder subfolders, like maybe the ‘docs’ folder? Or should I not do it at all?
FYI-- I set up a test project and an SVN repository to match it, added the project folder to the repository, then checked out the project folder to the original test project folder so that all the ‘.svn’ folders were in place in the project folder. Then I opened the project in Scrivener, made some minor changes, saved, exited, and committed the changes to the repository. Scrivener seemed happy with all of that when I reopened the project. Next, I did a backup of the project and took a look at the resulting zip file: Scrivener ignored all the various ‘.svn’ folders and just backed up its own files and subfolders-- so it glosses over the hidden ‘.svn’ files very well with no glitches.
So, this part seems to work OK, unless I’m missing something. I haven’t yet tried to restore a versioned file directly to my test Scrivener project, so I’m hoping that Scrivener doesn’t have some kind of indexing that will choke on the restored file. If it does, that should be an easy work-around.
Don’t forget that you’ll have to periodically SVN ADD new files that are created, and if you regularly empty your Scrivener project’s trash, you’ll also have to script the SNV RM operations to reflect the absence of those files.
Yep, doing the ‘adds’ and ‘commits’ are a fact of life with svn. However I hadn’t thought of scripting the the trash thing-- thanks for reminding me of that.
Scrivener maintains a complete index of the texts in the project, I understand. Presumably it therefore ignores your .svn files 'cos they’re not in the index. As far as I can see, putting them in somehow, risks scrambling your project as far as Scrivener is concerned, and making it unopenable … I’m not a member of the team or a programmer, but what you’re trying to do seems to be analagous to what happens when a project stored on Dropbox is screwed up by shutting down a computer before the .scriv is fully uploaded, and then opening the project on another computer.
But you almost certainly know more than me, so if you’re going to try it, do it on a temporary project or duplicate project that you can afford to scrap.
I think actually in this case the issue is that the .svn files are set to hidden, and so not seen by the zip compression library. I haven’t ever tried using SVN on Windows, so I don’t know that, but on UNIX based systems anyway, those files are hidden and so any tool that glosses over hidden files will ignore them.
There isn’t anything in Scrivener that tracks every single file in the project folder. The closest to that would be the .scrivx file, but even it doesn’t keep track of some things. Snapshots, for instance, have no oversight index at all. Their presence in the Snapshots folder is all that Scrivener uses to link them up to the proper items. There are a few other things like this.
Anyway, I’ve used various version tracking software with Scrivener before and have never run into problems with it that weren’t my own fault. Technologically there should be no issues.
Yes, the ‘.svn’ files are ‘dot’ files so they’re hidden. The closest I found to any indexing is the file list in the ‘scrivx’ project file, and the only thing that I could see that might cause a problem might be the ‘created’ and ‘modified’ properties in the BinderItem ID tags. But that’s minor, and an easy work around.
I actually wanted the svn for versioning rather than backup (I have an S3 acct for that, as well as a couple of external hard drives), so as long as I can get some kind of roll-back via svn, even if I have to hack it a bit, I’m happy.
Right, that .scrivx file is the closest thing, but it only describes stuff in the project binder and some meta-data type stuff. It doesn’t for instance, index its own internal backup file, binder.backup.
For versioning, having a familiarity with the schema of the .scrivx file will be helpful, especially if your are rolling back outliner adjustments. If an item is added (and so thus a suite of ##.* files in Files/Docs), then you’ll need to look up that ID in the .scrivx from that era and merge the proper elements back into the appropriate spot in the binder. This kind of piecemeal merging would need to be done by hand in many cases. Another thing you’ll want to consider when doing an operation like this is the search.indexes file, though at times it might be easier to just delete it and let the software regenerate it. Just note that this sort of thing can get fairly complicated. For example if the restored item was using a label that no longer exists, you’d need to find the label elements and restore those as well. It’s not a procedure I would want to do regularly.
You do know that the program has an auto-backup feature, right? Check the Backups tab in Tools/Options… and tweak the settings to suit your preference. By default it creates a total snapshot every time you close the project with a retention of five backups for each project. These are just zipped project files; if you need to restore from a particular slot, you’d replace the whole project with the restoration copy.
That’s what I meant when I said a work-around would be easy to hack-- if it came down to it I could just either hack the xml file (I’m not afraid of hacking the xml-- been writing html since 1993), or restore the particular revision by opening the corresponding version and manually updating the current project file in question. And there are other ways.
Yes, I know about the zip backups, and also snapshots although I frequently forget about snapshots. The zips as well as the current project files get backed up several times a day to my S3, but I like having the svn around for quick roll-backs-- I’m used to using svn since I use it for all my work projects.
Excellent, sounds like you’ve got a pretty good system. I use Dropbox for my automatic backup server-upload, and Git for versions off and on. It’s good to have about a half dozen copies of any particular slice scattered around the world.
I’ve got files spread out all over the place: S3, four external hard drives that I use for various levels of archiving, Dropbox, and more. I use Syncback Pro for scheduled local backups and Cloudberry backup for scheduled remote backups to my S3. And for increased redundancy on important items I use Jungledisk to make scheduled encrypted backups of things like ftp passwords, etc. Sometimes makes me feel like some kind of a digital squirrel, but it’s worth it if and when I get in trouble. I haven’t needed Git because there’s just one of me and I figured the distributed repository structure was overkill.
