At Crowd Favorite we use SVN at the core of our team development work. We recently tried to switch from Word and Excel documents to Pages and Numbers documents for estimates and proposals. Unfortunately, we’ve discovered that iWork breaks SVN.
The .numbers and .pages files are 
bundles 
– plain directories that OS X treats differently. Quite reasonably, as a cross-platform solution, SVN does not care a whit about bundles, and treats these as any normal directory and files. The problem appears to be that when saving new versions of these files/bundles, the .svn directories inside these bundles are removed/altered/damaged.
This is clearly a problem with bundles and the iWork apps, not SVN. At least that’s my view – read a counter-argument here.
More reading on the subject, including some work-around scripts:
I have to say, I’m more with Alex than Brian on this one. The problem seems to be the overloading of the directory metaphor to a ‘bundle’ — and yet, not respecting the way directories have always worked on UNIX-like OSs after overloading.
From Alex’s description, writing to a file in a bundle/directory causes apple to change or destroy things in that directory that it didn’t put in the bundle/directory personally. Not user friendly — I thought mac was _supposed_ to be the most user friendly, but this destructive behavior is a little disconcerting. And breaks SVN.
To be fair, I don’t believe this would break the source control system I use (Rational ClearCase — works on many UNIXs and Winders, but not OS/X) because ClearCase doesn’t store the directory versioning information in the directory, but in a data store of its own elsewhere on your box. If SVN changed it’s model to store the actual versioning info for any directory in a separate location, this would be no big whoop.
(I originally tried commenting on Brian’s site, but his blog software has a block on my net gateway IP that I share with thousands of other ppl)
Bundles hide the details of a collection of resources that wants to be treated atomically in some cases (ie, from the user’s point of view), but not atomically in others (eg, filesystems without metadata, developer access, version control systems).
I think the bundle abstraction is a nice compromise and improvement over the bare “hierarchy of files” lowest-common-denominator provided by today’s filesystems. SVN should be savvy to it and realize that a bundle will be treated atomically in some cases. Also, future filesystems might be implemented such that SVN couldn’t use its hidden-directory trick at all. SVN will probably need to adapt.
That said, XCode does *not* clobber the .svn directories inside its project bundles. And yeah, in the meantime it’d be nice to be able to check in iWork docs. 🙁
SVN should be savvy to it and realize that a bundle will be treated atomically in some cases.
How could SVN be saavy to some other program (like iWork stuff) deleting it without notification?
Also, future filesystems might be implemented such that SVN couldn’t use its hidden-directory trick at all. SVN will probably need to adapt.
Not if those future filesystems hope to follow the POSIX standard. Not much of a chance of any UNIX-derived OS not following that standard, for a looong time.
They should have used the zip trick. Just like .jar and .xpi (mozilla extension) files. Just zip files with 0 compression. Still fast (no decompression necessary), but 1 file, so much safer to transport around.
I agree, if they wanted it treated like a single file they should have used a single file.
Robert – the zip trick could work fine. However, some version control systems like Git don’t require the antiquated method of putting a special dot directory in every single directory. So, they’d be able to manage packages fine, and in fact, not have to treat them entirely as binary files, which could have it’s own benefits for sure.
How could SVN be saavy to some other program (like iWork stuff) deleting it without notification?
The point is that this problem has been around for a long time and is not likely to go away any time soon: a collection of resources that behaves atomically in some cases and not in others. *Some* kind of bundle abstraction is called for. Ideally, some platform-wide standard would expose APIs to deal with bundles, however they may be implemented on each platform/filesystem. Then we don’t have to rely on “tricks” at all.
My suggestion is not that subversion needs to respond to Apple’s clobbering of its .svn folders, but just that the problem is not so simple as “Apple has a bug”. From Apple’s perspective, the iWork document is always atomic to the vast majority of its audience: business/home users. Why should they assume that anyone would go embedding other stuff in there? They are no doubt aware of their apps’ less-than-ideal behavior in this case, but it’s no doubt a low priority for them.
I agree that it would be good for Apple to fix this in the short term; a long-term solution will involve subversion, too.
Not if those future filesystems hope to follow the POSIX standard.
In my experience, useful standards are susceptible to evolution.
Brian mentioned Git, Mercurial and GNU-Arch are two more SCM systems that don’t put crap in all your subdirectories, and shouldn’t have any trouble with bundles.
In regard to Eric, that kinda refutes your first point. Also, you failed to quote my “looong time” hinting that evolution was possible, but for compatibility reasons, don’t expect any change anytime soon.
[…] does Subversion hate iWork? I was just hit with the iWork/SVN bug that seems to be infamous among those using the two products concurrently. The problem, […]
[…] is not without its flaws, and I’ve been reading great things about Git and Mercurial recently, and the benefits these […]
[…] is not without its flaws, and I’ve been reading great things about Git and Mercurial recently, and the benefits these […]
I ran into this problem recently, and while I can see how this can be considered an SVN issue because of their architecture, I agree in this case the problem is iWork. I have tried this with OmniGraffle for example, and they don’t remove the .svn directories from their .graffle bundles, and everything works great.
I ran into this article: http://sadilek.blogs[...]cuments.html that has a nice bash script that you can run to regenerate the .svn folder before committing.
I have modified the script so that it can be run from the root of the svn checkout and it regenerates the .svn directory for all iWork files inside the checkout, so it’s a lot simpler to use. You can find the modified script here:
http://misc.oscarfer[...]m/fix_svn.sh
Hope it helps somebody! and let’s hope a future release of iWork fixes this (which is way more likely than svn getting fixed to handle problems like this).
Oscar.
Your use of images of hands making air-quote gestures would be considered a war crime in any civilized country. You absolutely sicken me.