How to get SVN to ignore Mac "._" files?

Question

My development server is accessed by several OSX users, and their OS tends to leave lots of unnecessary files around the place, all starting with dot underscore ("._"). I know OSX can be told not to create these on network drives, but they still sneak in. I'd like SVN to ignore anything starting with "._", but I can't seem to get it to work, even though it looks like it should be simple. I've added "._*" to the SVN global ignore pattern, but SVN is still trying to add and commit these files. Can anyone tell me what I'm doing wrong? My full SVN ignore pattern is:

global-ignores = *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo *.rej *~ #*# .#* .*.swp .DS_Store Thumbs.db ._* *.bak *.tmp nbproject

I don't know if it makes any difference, but I'm trying to set this on both Ubuntu and Ubuntu server by editing the /etc/subversion/config file.

Answer 1

I have a pre-commit hook that might fit the bill. This hook allows you to completely ban the use of certain file names based upon a regular expression. You can ban any file that starts with "._" and if someone tries to add one, they won't be able to commit it.

After a few rejected commits due to having "._" files, developers will update their global-ignores to include those files.

You can't set global-ignores for all of your users, but this pre-commit hook will encourage your users to set it on their own.

It works on the same principle of how electric sockets discourage users from sticking a fork into them. After the third or fourth time, even the most stubborn developers learn that it's not a good idea.

Answer 2

You can also use set the svn:ignore property and add "._*" and other desired values to it. Then the ignore values are in the repository and each working copy, rather than machine-specific configuration. However, both svn:ignore and the global ignore list can be circumvented.

Make sure the form of "svn add" you are using respects svn:ignore and the global ignore list.

Here is an excerpt from the svn docs (added emphasis):

Even if svn:ignore is set, you may run into problems if you use shell wildcards in a command. Shell wildcards are expanded into an explicit list of targets before Subversion operates on them, so running svn SUBCOMMAND * is just like running svn SUBCOMMAND file1 file2 file3 …. In the case of the svn add command, this has an effect similar to passing the --no-ignore option. So instead of using a wildcard, use svn add --force . to do a bulk scheduling of unversioned things for addition. The explicit target will ensure that the current directory isn't overlooked because of being already under version control, and the --force option will cause Subversion to crawl through that directory, adding unversioned files while still honoring the svn:ignore property and global-ignores runtime configuration variable. Be sure to also provide the --depth files option to the svn add command if you don't want a fully recursive crawl for things to add.

How to test if your ignore list is working

svn status

If it doesn't show up, and it's not versioned, then it is being properly ignored.

Barring proper ignores AND always using add appropriately, a pre commit hook like @David W. mentioned may be the last/only total defense...

Answer 3

Subversion uses the fnmatch() function for the ignores. So you have to use the pattern matching notation of that function.

The ignore section you posted should work. Are you sure you are setting it in the correct config file? There are multiple locations where svn reads those from.

On Unix-like systems, this area appears as a directory named .subversion in the user's home directory. In addition to the per-user configuration area, Subversion also recognizes the existence of a system-wide configuration area. [..] On Unix-like platforms, the system-wide configuration area is expected to be the /etc/subversion directory;