On Jul 24, 2009, at 1:21 PM, bradb wrote:
a known issue with svn and iwork applications is that on save, the applications delete all the internal .svn files. the "files" are really bundles.
This has actually been fixed with iWork '09. (This may not solve your particular problem but be aware that the newest version of iWork will actually store documents as zip files, not document bundles.)
there exist a number of scripts available that fix the problem by restoring the svn files from the repository while keeping the changed files. it would be great, since this IS a mac product, if versions could incorporate a feature to fix these files (which otherwise show up as obstructed in the interface.) otherwise, one has to go to the command line and fix the files before commiting. why pay for a gui if you still have to work at the command line ...
While this is true, the better solution is (1) for Subversion to deal properly with bundles, and/or (2) to zip bundles (whether documents, applications, etc.) before versioning them. This does not require command-line work, but it does require an extra step, which is unfortunate, but not something that can justly be pinned on Versions. Perhaps it would seem to be a "simple fix", it would require Versions to guess about obstructed files and attempt to recreate the .svn directories, but this isn't a simple problem, and more importantly, it's not Versions' problem.
To answer the last question, I would still pay for a GUI that vastly simplifies and streamlines my workflow, even if I had to drop to Terminal on the odd case. I'm not saying I wouldn't love to do "everything" from the GUI, but the fact that it's not entirely possible doesn't mean the GUI isn't worth using, even paying for. For example, branching and merging aren't yet (well) supported, but I still use Versions for the normal workflow of update and commit, etc.
smime.p7s
Description: S/MIME cryptographic signature
