And neither do Mega. It generally works like Dropbox. Box sometimes works like Dropbox and sometimes it doesn’t, and you never know beforehand what kind of day it is. An instant- or delayed-upload/download day .
After years of being on the side of Dropbox, it just works, I have had major problems with it–but not because of Scrivener. I have huge video files that I am trying to live in the cloud forever and only bring them on to the computer when absolutely necc. These files are 45-70 gbs. So it was draining my entire ISP load and then when it synced, it was not clear where my Dropbox files were in the process of syncing . Like i needed it on to make sure my project was synced up to dropbox, but leaving it on was burning data because of video.again, this is a dropbox ish.
For files that big, you don’t want a consumer “cloud” service, you want a dedicated corporate server. Consumer services just aren’t designed for that kind of volume.
Or else skip the internet altogether and use an external drive to haul the files around.
Katherine
I had this issue too (people I shared folders with put honking big videos in the folder). I also sync my ebook collection to DB but don’t want to download 4000 books to my ipad!
There is a way around this issue though. Put your videos in their own folder in DB and then in the options, select “don’t sync” (you can even select per computer/device). So, if I want one of the videos, I can select it in DB and download it when I want, but otherwise, it just stays in DB and nowhere else.
In my day job I run product management for a DevOps company that relies heavily on Git as the source of truth for large collaborative software projects. (Some of them with 100+ devs checking in changes to shared code.)
I would love to explore what it would take to set up a Git Repo that could handle the Merge and Conflict resolution for the underlying content.rtf and synopsis.txt files in a way that would be easy to use for people who don’t even know what Git is.
Is there a resource out there that explains the file structure of Scrivener such that we could take a shot at it?
Until you can get Git to parse and handle RTF files, there’s really no point in trying to go further. Once it can handle the RTF format, I suspect the rest would be fairly easy to do.
Devin is right, the issue is dealing reliably with RTF — RTF is great because it is, after all, plain text, but RTF is a pain because it is nowhere near as easy to parse as formats like JSON or XML, AND on top of that, Scrivener’s RTF has a bunch of custom additions to support features that RTF itself can’t. But this is all just parsing content, nothing is impossible. Several diff programs have converters for Word or PDF documents that extracts the text for comparison.
The “key” file is the .scrivx XML description file, that contains the map of all the document unique IDs in the bundle. This is really nice to parse, and gets you the binder names for all the otherwise anonymous content.rtf documents. Snapshots are quite straightforward, every document has a UUID, and snapshot directories link to that and have an index.xml file that stores the metadata for each snapshot. Settings are mostly text or XML.
So understanding the scrivener bundle is really straightforward, the key to a nice Git interface is dealing with RTF. It would of course be great to get a nice Time Machine like interface to Git+Scrivener 8) 8) 8)
I get the RTF file complexity. We wrote our own XML parser for merge for the same reason, Git does a passable but not perfect job of merging very large and regular XML files.
So looks like that is where the most important investment in time will be.
Thanks also for the direction on the XML file.