Scrivener and Subversion?

User avatar
Eiron
Posts: 452
Joined: Tue Jul 11, 2006 4:01 pm

Fri Feb 09, 2007 12:59 am Post

Three year olds are great - 3 to 5 is the golden age.

je
jeremydouglass
Posts: 38
Joined: Tue Jan 09, 2007 10:38 pm

Fri Feb 16, 2007 6:45 pm Post

I just tried to do the same thing last week - I friend and I wanted to see if we could collaborate with a team - each person would buy scrivener and we would check our changes in and out of the subversion repository. Given that a scrivener document is essentially a folder full of little files, it seemed ideal - way better than playing the track changes game with Microsoft Word.

But I ran into the same hitch you did. I believe that subversion stores absolutely everything in directories named .svn - one per folder. You'd probably want to do something like this.

1. Close Scrivener.
2. Check the document in to subversion.
3. Check out a working copy.
4. Run a backup shell script / folder synchronizer, but only copy the .svn directories.
5. Edit Scrivener.
6. When you want to update, close Scrivener
7. Run a restore shell script, copying the .ssh directories back.
8. Use svn or a subversion client to register your changes and commit to the server.

The alternative is to wheedle Kevin into exempting the .svn folders from the purge - no clue how hard that would be though (the exemption OR the wheedling). :D

I'll probably let it lie for a while before I dust myself off and try to write a shell script and make it a droplet. Still, team-manuscript editing with scrivener does sound like fun....
Last edited by jeremydouglass on Fri Feb 23, 2007 8:47 am, edited 1 time in total.

je
jeremydouglass
Posts: 38
Joined: Tue Jan 09, 2007 10:38 pm

Thu Feb 22, 2007 12:00 am Post

This is a technical overview of how to use set up Scrivener documents for use with the free content versioning system Subversion.

It combines a basic description of adding a Scrivener document to an svn repository with two advanced gotchas - the need to cache .svn data, and potential problems with the binder file. It also assumes that:

1. You already know the very basics of subversion
2. You already have subversion client tools installed locally, and already have permissions to create a subversion repository somewhere else.
3. You have a Scrivener document that you want to track changes on and/or collaborate on.

# SETTING UP SUBVERSION+SCRIVENER #

During this process, *do not* run Scrivener (for reasons discussed in "Working" below).

1. Create your subversion repository, "scrivenerdocs," which will hold all your collaboratively authored Scrivener documents (for example, on a remote server). In Terminal:

ssh myuser@mysite.com
cd mydirectory
svnadmin create scrivenerdocs
exit

Note that some hosts allow this step via control panel.

2. Check out a blank working copy from the server repository to any place on your hard drive - for example, a special section of your user folder. In Terminal:

cd ~
mkdir subversion
mkdir subversion/checkouts
svn co svn+ssh://myuser@mysite.com/mydirectory/scrivenerdocs ~/subversion/checkouts/scrivenerdocs

3. Add a Scrivener doc to your working copy and mark it as added. In Terminal:

cp -r ~/Documents/MyDocument.scriv ~/subversion/checkouts/scrivenerdocs/
svn add ~/subversion/checkouts/scrivenerdocs/MyDocument.scriv

You can add as many Scrivener docs as you like right away. Note that from now on, the .scriv file in /checkouts will be your active version - the one in /Documents you can delete or archive.

4. Cache all your .svn folders to another directory (for reasons discussed in "Working" below).

sudo rsync -av --include "*/" --include ".svn/**" --exclude "*"\ ~/subversion/checkouts/scrivenerdocs/ ~/subversion/checkouts/scrivenerdocs-cache

5. Upload the file to your repository

svn commit ~/subversion/checkouts/scrivenerdocs -m "Initial import of my very first Scrivener file"


# WORKING #

Now you can get working - as many people as you like can check out copies and make changes, and all the changes will be tracked and combined. However there are still two big problems:

## Problem: Scrivener auto-deletes the .svn subfolders ##

Deleting these folders breaks any Subversion working copy as soon as the program is run. This is a frustrating problem (as there doesn't seem to be any reason for it), but it is surmountable. This is why we created a cache of .svn folder data. Every time we checkout, update, or commit, we can restore the cache before doing it, and backup the cache after.

1. edit in Scrivener
2. close Scrivener
3. restore .svn from cache

sudo rsync -av --ignore-existing --include "*/" --include ".svn/**" --exclude "*" ~/subversion/checkouts/scrivener-cache/ ~/subversion/checkouts/scrivenerdocs;

4. update local .svn info, check remote changes, and commit changes to the remote repository

svn status ~/subversion/checkouts/scrivenerdocs
svn update ~/subversion/checkouts/scrivenerdocs
svn commit ~/subversion/checkouts/scrivenerdocs -m "Latest changes"

5. backup latest .svn to cache

sudo rsync -av --include "*/" --include ".svn/**" --exclude "*"\ ~/subversion/checkouts/scrivenerdocs/ ~/subversion/checkouts/scrivener-cache

Yes, this means that the whole process is more complicated. I'd like to wrap these up in one or two scripts, but I haven't yet.

## Problem: MyDocument.scriv/binder.scrivproj is binary ##

That means no manually merging the file if someone else has edited the repository. In practice, this means that editing the content of entries is easy, but adding, deleting, moving or deleting entries in the binder creates a potential sync problem - if two collaborators change the binder, then one will blow away the other's changes, with the second editor either leaving binder entries pointing to missing files that the first deleted or omitting binder entries pointing to orphaned files that the first added.

Currently the only solutions are:

1. agree that only one collaborator will perform binder edits, the rest will edit existing documents.
2. If a conflict occurs on binder.scrivproj, check out a new working copy and manually merge the two by dragging and dropping resources in Scrivener.

That is a shame, as one big part of the appeal of Scrivener is editing the collection using its binder interface. However the only way that could really change is EITHER if the binder.scrivproj file were text-based OR if the authoritative binder information was stored in the files themselves (e.g. spotlight comments) and the binder was rebuilt dynamically on startup from present assets - in other words, the program as a whole would have to work so differently from how it currently does that it aint gonna happen. Much more likely would be leveraging some merge import or merge function in Scrivener allowing you to combine two Scrivener projects.

an
andyb
Posts: 2
Joined: Fri Feb 23, 2007 12:53 am

Fri Feb 23, 2007 1:00 am Post

jeremydouglass wrote:This is a technical overview of how to use set up Scrivener documents for use with the free content versioning system Subversion.


Great post Jeremy! I think an initial and relatively simple fix that Keith could make would be to stop Scrivener from removing the ".svn" directories. This is possibly easier than having you write scripts to automate the caching of these directories.

The binding update issue is always going to be problematic. Concurrent updates to the project/document structure will always lead to inconsistencies that can only be addressed by a human user. As long as people understand this when they're collaboratively editing, then you can implement processes/controls to make sure it doesn't happen. The other solution is a user-driven merge, but this is a non-trivial undertaking.

User avatar
KB
Site Admin
Posts: 20762
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Fri Feb 23, 2007 10:04 am Post

Hmm, I'm not sure what you mean - there is no code in Scrivener that removes any .svn directories or anything else that it doesn't know about within the package. Weird.
Best,
Keith

je
jeremydouglass
Posts: 38
Joined: Tue Jan 09, 2007 10:38 pm

Wed Mar 07, 2007 1:04 am Post

I think erikmkeller was right early in the thread when he blamed AppKit for filtering rtfd directories. After a bit more looking, I also think I found a solution: "[OS X] Preserving .svn directories in nibs; restoring nuked .svn directories (in rtfd)." http://svn.haxx.se/dev/archive-2003-02/1321.shtml (update - fixed URL)

Keith, if you were willing to patch this in-app (and I understand this is an edge case - not really your problem) the above solution looks like the way to go.

But first, humor me and let me prove the problem actually exists:

1) New Project in Scrivener: ~/Documents/temp.scriv
2) In the Scrivener default Untitled document, type "foo" and force Save
3) In Terminal, let's add hidden svn data:

ls -a ~/Documents/temp.scriv
.
..
3.rtfd
3_notes.rtfd
BinderStrings.xml
binder.scrivproj

mkdir ~/Documents/temp.scriv/3.rtfd/.svn
touch ~/Documents/temp.scriv/3.rtfd/.svn/myvitalsyncdata
ls -aR ~/Documents/temp.scriv/3.rtfd/
.
..
.svn
TXT.rtf
myvitalsyncdata

6) In the same Scrivener Untitled document, type "bar" and force Save
7) Back in Terminal, check the directory again:

ls -aR ~/Documents/temp.scriv/3.rtfd/
.
..
TXT.rtf

....svn and myvitalsyncdata just disappeared.

Keep in mind, I understand if you don't want to deal with this - SVN use is rare and pretty geeky. If you do patch this, however, I can continue my experiments with collaborative editing with Scrivener - and others may use it to keep true versioned archives of their documents.
Last edited by jeremydouglass on Thu Mar 08, 2007 12:55 am, edited 1 time in total.

zu
zuzu
Posts: 11
Joined: Sun Feb 04, 2007 10:23 am
Location: UK

Wed Mar 07, 2007 10:34 am Post

jeremydouglass wrote:I think erikmkeller was right early in the thread when he blamed AppKit for filtering rtfd directories. After a bit more looking, I also think I found a solution: "[OS X] Preserving .svn directories in nibs; restoring nuked .svn directories (in rtfd)." http://svn.haxx.se/dev/archive-2007-02/0346.shtml


This worked better for me: http://svn.haxx.se/dev/archive-2003-02/1321.shtml I'd also like svn support if at all possible