views:

453

answers:

3

I have various files that I want to be ignored by SVN when committing. I know that I can go into TortoiseSVN and ignore them in various ways. I know that I can run svn propedit svn:ignore from the command line to do the same thing.

The problem is that I have to have everyone on my team to do that, which is a pain. Is there a way that I can put some file in a folder or set something in my SVN repository that tells it to never check a certain file in?

A: 

Prepare a proper clean structure in SVN and then ask all users to checkout fresh.

Dima
+13  A: 

Once you have setup your svn:ignore properties (either using TortoiseSVN or the commandline), you should commit these changes.

As soon as your team-members update their working copies, they will also have the svn:ignore properties set, and the files/folders listed in the properties will be excluded from commits.

See this page for details: TortoiseSVN - Ignoring Files And Directories

Note:

If you have already commited some file which should be ignored, then you first have to delete them from the repository before you can ignore them (see rmeador's comment)

M4N
it's worth noting that svn:ignore only ignores non-versioned files. If the files have already been committed, they will not be excluded from commits. svn:ignore will also not prevent you from forcibly added the ignored files to version control.
rmeador
Thanks for your comment. I updated the answer.
M4N
If you set it to recursive when you add the properties though it will update all files and folders (big ass commit) but sorts out the problem mentioned above :o)
Chris M
+1  A: 

An alternate approach that I use because I prefer not to litter my repositories with svn:ignore properties for some files (like IDE files, OS files, files to be ignored across multiple projects, etc.) is to keep a config file in a different repository. In that file, I set certain patterns in the global-ignores list. I then check out that config file to ~/.subversion and have my team members do the same.

By doing that, we all have the same global config file and it can be svn updated on an as-needed basis. I find this way useful when I have multiple projects going on (which is almost always) and they share many of the same strategies.

Rob Wilkerson