[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problem with ._ files on Mac OS X and SVN Autoversioning on

From: Ryan Schmidt <subversion-2006Q1_at_ryandesign.com>
Date: 2006-02-02 13:41:54 CET

On Feb 1, 2006, at 23:18, Matthew Willis wrote:

> To enable easier access for some content developers who must work
> through SSL VPNs, I recently enabled SVN Autoversioning.
>
> The Mac OS X users can mount the WebDAV share just fine, and their
> changes are committed successfully.
> However, since Mac OS X doesn't think the WebDAV server can handle
> xattr information, it creates ._ files on the WebDAV share, and
> these are dutifully added to the repository.
> The problem then appears when a Mac OS X user using standard
> Subversion (rather than the WebDAV share) attempts to update their
> working copy.
> They receive errors such as
> svn: Can't copy 'assets/48/final/.svn/tmp/text-base/._.DS_Store.svn-
> base' to 'assets/48/final/._.DS_Store.tmp': No such file or directory

I've never tried to use auto-versioning yet, but this sounds pretty
awful. Not that it's at all unexpected, given how Mac OS X works.

> I've read the threads on the developer list regarding resource
> forks, non-HFS+ filesystems, ._ files, and xattrs, but this I
> didn't see this particular scenario mentioned.
>
> Does anyone have a suggesstion as to how to prevent this problem?

You must not write these ._ files to the repository. You must teach
OS X not to write these files there; I know of no way to do that,
however. You may want to open a bug in Apple's bug reporting system [1].

I think the ._ files will only be created if the file has a resource
fork, or, under Tiger, extended attributes. So do not create files
with resource forks or add extended attributes to them. If your
applications automatically do so, you should first save them to a
local volume, strip this extra information [2], then copy it to the
Subversion WebDAV volume.

The .DS_Store files are another matter. They're created by the Finder
to store column-size and -order information and icon position and
that kind of thing. I don't think those belong in the repository
either, but I know of no way to prevent the Finder from creating
them. Perhaps an alternative file manager, like Path Finder, might
work better. Or perhaps a pre-commit hook, about which I'll talk more
below, would suffice.

I can't understand why there would be a ._.DS_Store file as in your
error message, since .DS_Store files should be data-fork-only...

> Are commit hooks invoked when using autoversioning?

Yes.

> If so, could I create a hook that would silently neglect to commit
> the ._ files?

No. A commit cannot [3] change a transaction. It can only reject a
commit if it doesn't meet whatever requirements you define. So you
could at least prevent people from committing ._ and .DS_Store files,
and output an error message which refers people to a web page
explaining how to avoid the ._ files, for example. Er... the message
would, of course, not be displayed by a client just using the auto-
versioning WebDAV mount... the user would probably see the OS's
normal error message that the volume couldn't be written to. That
could be annoying / confusing.

[1] http://bugreport.apple.com

[2] I use the attached "killres" shell script when I want to remove a
file's resource fork. I don't know if it works perfectly in all
cases, but it works well enough for me. Xcode must be installed for
this script to work.

[3] It technically can, but definitely should not, because it will
screw up the client's working copy, which will think it is up to date
when in fact it is not. There's a tiny chance that just excluding ._
files might not be a catastrophe, but I wouldn't want to try it either.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Received on Thu Feb 2 13:45:40 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.