Does SVN have an equivalent to .gitattributes?

Question

Background:

I have two Unity3d projects:

• The first whose Unity preferences are set to 'mixed asset' mode (some files are text, some are binary) and
• The second whose preferences are set to 'force text' (most binary files are translated to YAML text, so nearly all files can be diffed).

In order to set the 1st project's files to text/binary, our ~/.subversion/config file has svn auto-props enabled along with the list of files and their svn properties (*.cs files set to svn:eol-style=native, *.unity files are set to svn:mime-type=application/octet-stream, and so forth).

Problem:

Since our second project now supports a text mode for all the files, we would need to use a different set of auto-props rules so the *.unity files are now handled as svn:eol-style=native.

I see that git can use .gitattributes which is on a per-project (or per-directory) basis, so we could have this functionality. Can SVN do this with some sort of file we can share in our repo so everyone who commits will use the same default settings?

Answer 1

One of the things you must understand that in git there's no real difference between a repository and a working directory. When you pull from a parent repository, you create your own repository.

.Gitattributes affect your local repository and only your local copy. Someone else can change their .gitattributes for their repository. After all, it's their repository. If a parent repository is receiving changes, it can use a pre-receive hook to verify the retrieved packet to make sure it follows the parent repository's policy. You shouldn't use .gitattributes to enforce policy, only to help you follow policy.

Subversion's auto-properties configuration is similar. It affects all working copies of that user. There's no individual configuration for each working copy. You can use a --config-dir parameter on many Subversion commands to specify a different Subversion configuration file for that operation, so you could have multiple configuration files and use --config-dir to specify that file. It's not convenient, but it's possible.

If you want to make sure your properties are set correctly, you need a pre-commit hook that checks the properties on a commit and rejects commits with invalid properties or property values on the files. I have a pre-commit hook that can do just that.