Once it’s ready, I’m hoping to do a public beta of 1.04 for exactly this sort of thing. Basically, I will just place a link to it in the beta forum while I update the Help files and get the installers ready, before making it official. Hopefully I should be able to do this next weekend or the one after at the latest.
Best,
Keith
I am one of those who use Scrivener both for creative writing but I am also trying to adapt my academic writing to this tool with varying success. MMD is a step in the right direction and having version control would be another big one. (Plus true file comparison but I am not going to bring that up again here).
Unless I am wrong, isn’t Leopard supposed to sport ZFS the zeta file system devised by Sun to make the *NIX geeks happy? And doesn’t ZFS feature version control on the OS level? I have no idea what it takes the developers to make their applications actually make use of this feature but maybe they would not have to reinvent the wheel to make version control (at a very fine granularity level at that) available transparently for the non-geek user.
I’d love to hear from someone in the know.
Prion
Last I heard, there are some indications that someone in an Apple lab is playing with ZFS, i.e. one mention in one header file. My understanding of the current situation: Chances of Leopard being ZFS by default: zero. Chances of Leopard supporting ZFS in an unofficial fashion: slightly more than zero. Chances of 10.6 or 10.7 supporting ZFS? Could definitely happen.
I think the whole ZFS thing got started over speculation about how Time Machine was going to work. We know now how it works, and ZFS aint it:
[Edit]…oops- turns out I’m way out of the loop. Looks like ZFS support for external storage in OS X rather than boot is quite possible, there are strong indications it could be in Leopard:
news.worldofapple.com/archives/2 … x-leopard/
Sorry about the above FUD
If you want to use a content versioning system with Scrivener, read on. If you don’t know what that is or why you would do it, this probably isn’t for you. These notes supersede previous advice on cache scripting and installing svk as a workaround.
As of Scrivener 1.04b, single user content versioning just works with one checkbox, and collaborative editing works quite well if you are careful about binder edits. Simultaneous adding is not recommended.
Special scripting or svk are now unnecessary to get Scrivener projects working with Subversion (or CVS). These instructions supersede my previous two write-ups, which originally suggested 1) use scripting to cache your .svn folders and pray, then opined 2) instead, install svk as a middleware layer between scrivener and subversion. For those who still like svk clean copies, those second instructions still work fine (although you can’t use SCPlugin or any subversion software with svk). For those who want plain subversion + Scrivener, the changes in 1.04b now fully support content versioning for archiving (no more broken rtfds) and largely support collaboration (with a few significant ‘gotchas’ detailed below).
A single user can get their Scrivener project ready for archival backup in a Subversion repository, just by check the box in Scrivener preferences and saving. Make sure the project is closed, then update and commit to the repository as normal. The resulting backups are like snapshots, except they take up a small fraction of the space (only actual changes are saved, not full file sets) and are maintained separately from your primary document, which stays lean. You can keep as many Scrivener documents as you like together in one repository, or keep each in its own repository.
Subversion supports fine-grained reversions (picking out specific changes from specific documents). You may want to do this by checking out old versions and manually pasting changes back in.
ADVANCED: Using normal SVN reversion is perfectly possible,
but it may raise conflicts between the state of the resource
files and the state of the project files binder.scrivproj or
BinderStrings.xml - for example, the text reverts but the
binder title and metadata don’t, or deleted documents are
restored to the project folder but don’t reappear in the
binder column and so are effectively invisible, etc.).
For those comfortable with FileMerge etc., the advanced
method works just fine if you treat Binder.xml like any
other piece of code.
Multi-editor and simultaneous collaboration works quite well, but you will have to merge changes if you and another editor simultaneously edit the same page at the same time - work is smoother when different editors stick to different parts of the project, as merging all happens automatically. Simultaneous adding of pages requires both manual file renaming and advanced xml editing to resolve and is not recommended.
If you want turn-taking collaboration with other editors, Scrivener again works seamlessly with Subversion - just run svn update before you edit and run svn commit after you are done, and everything should proceed as smoothly as in single user. In the case of overlapping collaboration, Scrivener is easy to use - in most cases. When one editor adds new text documents and another editor renames and edits an old document at the same time, these changed are picked up and merged intelligently to each on the next sync. When you see a couple dozen changes from each editor merge silently together, it is really gratifying.
Three things to watch out for:
I occasionally got a conflict in ui.xml which could just be force-reverted or resolved - it appeared to be from things like the different editors being on different panes when they closed, or panes being set to different views. Note that you can change ui.xml just by opening Scrivener to browse a document (without actually editing it), so changes in it may crop up even when turn-taking.
The normal conflict situation in content versioning applies of two editors changing the same individual document - then you have to resolve changes (e.g. picking one over the other or using FileMerge). For people familiar with this already, but used to plain text documents, you may not know that FileMerge has an RTF mode… for people not familiar with source control or merging, I’d suggest avoiding this process unless you are feeling adventurous - it isn’t as seamless a user experience as Word "“Merge Documents,” although they are conceptually the same.
The more difficult failure case is when binder additions or reorderings are performed by multiple editors - something that Scrivener is just not designed for. If both editors simultaneously add a 5th document (called “Introduction” and “Conclusion” respectively), Scrivener will autoname both documents 5.rtfd, and merging will be quite difficult (as it requires both renaming one of the documents and manually editing Binder.xml before conflicts can be resolved). You can make easy rules for dealing with this situation: 1. Only one editor adds documents to the binder, the others may only modify them (no binder merge headaches), or 2. The second person to attempt adding has to revert to the latest copy and paste in their new documents.
Here is the example setup I used. It assumes you have already installed subversion on your local machine are somewhat familiar with it. I used SCPlugin (the Subversion Finder plugin) to make my adds, commits, and updates, but I also provide Terminal commands below.
At this point you can try making simultaneous and overlapping changes of various kinds and testing what happens. I have not yet tested advanced features like embedded links / footnotes / etc. Keep these things in mind:
Thanks! I’ve updated the FAQ entry on SVN to point to this post as a source of detailed information.