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 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 ignore
