Regarding bundle files, it's really surprising to me that not more developers safeguard the .svn folders in those during a save. We have one internal app that uses bundles for its file format (a localization tool) and I can't say it was all too hard to make sure the .svn folders are persisted between saves.. All that said, most apps don't check for those, so it's definitely a pitfall.
I have seen some scripts online that restore .svn folders in bundle files, by renaming the modified file, copying the original over from the BASE revision of the file that's stored locally, and replacing the contents of the BASE copy with what's in the bundle. Tricky stuff. Personally I just avoid versioning bundle files. With regard to CR or LF line endings, you can set a property on text files to automatically convert them to the native type in working copies. To do this in Versions, select a file in the working copy Browse view, show the inspector, and set the popup under "Line Breaks" to "Native". More info about this feature of Subversion is offered over here: http://svnbook.red-bean.com/en/1.5/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style The Icon files are indeed a problem, although few people actually run into it. Versions doesn't do anything right now to work around this issue. We usually recommend people to add them to their list of globally ignored files in their .subversion/config file for now, but hope to have some kind of workaround implemented in Versions at some point. Another pitfall, but isolated to cross-platform environments is an issue that pops up here on the Versions google group every now and then, regarding non-ascii characters in file names. If you commit a file called "Chêvre.txt" on windows, check it out on a Mac and make changes to it there, SVN will see two "Chêvre.txt" files, a missing one, and an unversioned one. The cause of this problem (simplified explanation) is that Windows can encode these special characters in two different ways in a file name, both are seen as distinct from eachother by Subversion. Mac OS (or more precisely: HFS+) can accept file names with either encoding, but always stores them with only one encoding, the one that's not the default on Windows. The result is that the modified file looks like it's another file even though the human-readable file names are identical. Ocassionally you'll run into someone's workaround online for the problem, but I have yet to run into a really robust solution that'll work in all cases. Afaik. the Subversion community is still trying to figure out what the best 'real' solution for this problem is. The only real workaround for now is to delete the missing file and add the unversioned file, other platforms will respect the character encodings generated on the Mac. A final pitfall, but really an edge case, is that the version of OpenSSH bundles with Mac OS X has a problem with terminating ssh processes that are done with their task, they tend to linger around eating up system resources instead of properly terminating. But (if I remember correctly) you'll only run into that problem with Subversion 1.6.0 and 1.6.1 where the workaround in Subversion's code was temporarily ripped out. With the reservation that I may have forgotten something, these are the only notable Mac-specific pitfalls – beyond the ones you listed – with Subversion that I know to exist. All the best, - Dirk the Versions team On Nov 7, 2:05 am, Rob Rye <rowen...@gmail.com> wrote: > I have a long and frustrating history with bundles and their > interactions with subversion. > > The short answer is that Apple and the developers of subversion argued > for years over how this problem should be solved. In the end, Apple > abandoned the bundle structure in iWork '09 (though one can still > choose that structure it is not the default). Also, OmniGroup used > bundles for some of their applications (e.g. OmniOutliner), and then > offered a "save as flat file" option to accommodate svn users. > > There are scripts out there for checking bundles into subversion. The > makers of ZigVersion (a long-abandoned MacOS X GUI for subversion) > probably still have one available for download, if you search their > website for > > update_bundle.tar.gz > > However, it sounds like you wanted a GUI workaround. I am skeptical > about anyone having come up with one, as their having done so might > well have saved the bundle structure for iWork '09. > > On Nov 5, 2009, at 8:50 AM, Rob Lewis wrote: > > > > > > > Forgive my talking over my head here; if it weren't for Versions I > > probably wouldn't be able to use Subversion at all. > > > I happened to see an article in the January 2009 issue of MacTech > > magazine, called "(Avoiding) Subversion Troubles on Mac OS X". It > > mentions a few possible pitfalls: > > --Invisible "Icon" files with a CR as the last character in the > > filename. It says they can corrupt the repository and must be ignored > > by svn. > > --NSDocument deletes the .svn folder when saving bundles. > > --Problems mixing Mac- and Windows-style line endings in files. > > > I was wondering if Versions has workarounds for these issues. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Versions" group. To post to this group, send email to versions@googlegroups.com To unsubscribe from this group, send email to versions+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/versions?hl=en -~----------~----~----~----~------~----~------~--~---
