iWork vs. CVS

/ joeygibson

I recently bought the new iWork ’08 suite from Apple and have started using the tools for stuff I used to use NeoOffice for. But I noticed something yesterday that is disconcerting.

Like a lot of people, I store my documents in a CVS repository that is backed up to another disk. I checked in a few documents created with Pages and Numbers, and everything seemed fine. That is, until I re-saved any of the documents.

The problem lies in the fact that a “document” for Pages or Numbers (and probably for Keynote as well) is not a monolithic file like a .doc file from Word. They are directory structures (“bundles” is the Apple term) that the Finder and the applications that use them treat specially. Any program in the /Applications folder is the same type of thing. When you check something into a CVS repository, CVS creates a hidden CVS directory in each sub-directory of the thing being checked in. After checking in one of these documents, I went into the document through Terminal and verified that the CVS directories had been created. So far, so good.

When things went awry was when I re-saved a document. Instead of just changing the necessary files inside the “document,” Numbers deleted and re-created the entire directory structure. Thus, those CVS directories were toast. There’s no good way to recover from this, because those files now look like non-CVS files, but the server already knows about them. To my knowledge, there’s no painless way to handle this situation.

I don’t believe that Subversion is in any better position. When using SVN, you get a .svn directory created in each sub-directory of the document, but those will also get whacked when the document is re-saved. I haven’t tested that assumption, but it seems logical.

I tried to come up with a solution to this, but I’m stumped. I looked into cvswrappers just to see if it could help, but it doesn’t look like it. I also considered a pre-commit script and a post-checkout analog (if there is one), but this didn’t seem like it would really get us there.

The only solution I see is for Apple to stop whacking the directory structure and just change the files inside it that it needs to, and stop molesting the version-control special files. Maybe they can implement this behavior when they add support for OpenOffice and the OpenDocument format…

7 thoughts on “iWork vs. CVS”

  2. It’s a common problem with file packages like the documents put out by iWork. There may be hack-ish solutions like an input manager that hooks into the app and overrides document saving (there used to be something similar for NIB interface files back in the NeXT days IIRC) but best would be if the various version control systems came to understand opaque folders for versioning.
    To my knowledge, the one version control system that sidesteps this issue entirely (since it doesn’t place dot-files into the versioned hierarchy of files) is Git. It’s said to be a bear to install though.

  3. Not sure if you’re interested in changing version control systems, but Mercurial doesn’t put a file in each subdirectory, only the top-most one.

  4. It’s interesting that MRO should mention NIB files. I have been saving my Cocoa projects in a CVS repository for months, and have had no problems. It would seem that IB does the “right thing” when it saves changes to a NIB, and only touches those files inside the NIB directory structure that need touching. That’s all I’m asking for from iWork.
    As for Mercurial, I’ll take a look, but I’m an old CVS guy from way back. I’ve been toying with SVN for a little while, but I would be hard-pressed to introduce a third VC system.

  5. The old version of Keynote had the same issue. It just rewrites the bundle when saving and thereby removing all .svn files which messes up with subversion. I have a very crude script that fixes that. Just run the script before syncing with subversion. (I haven’t tested it with the new version of Keynote yet!)

    #!/bin/csh
#update a keynote file (which actually is a directory)
#copies the keynote directory
#reverts to the previous version, copies changed directories
#from copy to original directory
#after that changed keynote file may be committed
mv "$1" key.tmp
svn update "$1"
mv -f "$1"/.svn key.tmp
mv -f "$1"/Contents/.svn key.tmp/Contents
mv -f "$1"/thumbs/.svn key.tmp/thumbs
rm -r "$1"
mv key.tmp "$1"

    Edited By Siteowner

  7. SVK works with existing SVN repositories and adds a lot of very nice features, one of the best being no .svn files anywhere. It’s as easy to install as SVN is.

Comments are closed.