Configuring the SVN Local Global Ignore Pattern

Every team that manages code with SVN knows the awkward moment: you run svn status and dozens of files that should never be versioned stare back at you — node_modules, __pycache__, .idea, .DS_Store. One careless svn add -A later, the whole lot is committed, the repository bloats, and every checkout drags the junk along. The Global ignore pattern closes that gap: configure it once in your SVN client and every working copy on your machine automatically ignores those files.

Where to configure it

The most common entry point is the TortoiseSVN GUI client:

Settings → General → Global ignore pattern

Type the rules into the box, separated by spaces. TortoiseSVN ships with a default set, but it is usually not enough — you will want to extend it.

If you prefer the command line, SVN keeps the global ignores in the client configuration file: ~/.subversion/config on Linux/macOS, %APPDATA%\Subversion\config on Windows. Open the file, locate the [miscellany] section, uncomment the global-ignores line, and set it to:

global-ignores = *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo *.rej *~ #*# .#* .*.swp .DS_Store obj Obj bin Bin Debug debug *.suo *.tmp *.user *.log *.pdb *.refresh .idea node_modules .git packages TestResults .project .settings

After saving, newly created working copies pick up the rules immediately; existing checkouts pick them up the next time the client is opened.

One extra point: TortoiseSVN reads and writes the very same config file, so changes in the GUI and on the command line affect each other — the GUI is just more approachable for colleagues who are not used to the config format.

Recommended global ignore rules

The following is a practical set of global ignore rules covering build artifacts, system files, and files generated by development tools:

*.o *.al .libs *.so.[0-9]* *.a *.pyc *.pyo *.rej *~ #*# .#* .*.swp .DS_Store obj
Obj bin Bin Debug debug *.suo *.tmp *.user *.log *.pdb *.refresh .idea
node_modules .git packages TestResults .project .settings

Rule explanation

  • Build artifacts: *.o, *.a, *.libs, *.so.[0-9]* are intermediate objects and libraries generated by C/C++ compilation;
  • Python caches: *.pyc, *.pyo are Python bytecode caches (Python 3 also creates __pycache__ directories — add them too);
  • Editor/system temporary files: *~, #*#, .#*, *.swp are editor temporary files, and .DS_Store is the macOS folder metadata file;
  • Dev tool directories: .idea (JetBrains IDEs), .settings (Eclipse), node_modules (Node.js dependencies), packages, TestResults, etc.;
  • Logs and temporary files: *.log, *.tmp, *.user, *.refresh, *.pdb, etc.

A concrete example

Say you maintain a project that mixes a Node.js backend, Python scripts, and Java tests. Before configuring anything, svn status shows node_modules/ (tens of thousands of files), __pycache__/, .idea/, and a pile of *.log. Once the rules above are in place, all of that disappears from the status list, which now shows only the source files you actually changed — and svn add -A becomes safe again. For polyglot projects, a machine-wide global-ignores is far less tedious than writing svn:ignore by hand in every repository.

The team scenario is even more typical: a team moved from solo maintenance to three-person collaboration, and the first svn commit pushed up a 500MB node_modules. After svn rm --keep-local node_modules removed the dependency from the repository and the ignore rules were added, the repo size returned to normal and teammates' checkout time dropped from over ten minutes to a few seconds. In Git this is .gitignore; in SVN it is global-ignores combined with svn:ignore.

Frequently asked questions

  • How are spaces in rules handled: global-ignores separates rules by spaces, and in most cases you never need to match a space; add escaping only for unusual characters.
  • How do I clean up an already-committed node_modules: ignore rules do not reach back into history — run svn rm --keep-local node_modules, commit, and only files added afterwards are ignored.
  • Which rules are useless on Windows: platform artifacts differ; on Windows projects use *.obj, *.suo, *.pdb, *.dll, *.exe and similar instead.
  • Can a wrong rule delete files: ignore rules only act on untracked files; a mistake causes at worst a missed commit, never a deletion or modification, so the risk is low.
  • Need to commit one ignored file anyway: svn add --force <file> overrides the global ignore for that one file only; it stays ignored afterwards.
  • Do the rules reach teammates: global-ignores is local and does not sync automatically; to align the whole team, use the versioned svn:ignore property.
  • svn status still shows ignored files: double-check the rule syntax and that the file is really untracked; ignore directories by bare name (e.g. node_modules) — a trailing slash turns it into an exact-path match.
  • How to set it up by default in new repos: TortoiseSVN can export the global ignore rules to new repo templates, or drop an ignore-rule note into the repo README for newcomers to follow.

Notes

  1. The Global ignore pattern takes effect globally on your machine and applies to all working copies;
  2. It only affects files not yet under version control. Files already svn add-ed or committed will not be ignored by this rule — so configure it early, before the damage is done;
  3. If an ignored file must be committed, use svn add --force to add it explicitly, or temporarily adjust the ignore rules;
  4. For ignore rules shared by a team, configure the versioned svn:ignore property on the repository root so all collaborators get the same behavior. From the command line:
svn propset svn:ignore "node_modules
__pycache__
*.log" .
svn commit -m "set svn:ignore"

Summary

Filling the SVN Global ignore pattern with rules such as *.o *.a *.pyc *.pyo *.log node_modules .idea .git prevents build artifacts and IDE configuration from being committed repeatedly, keeping the repository clean. For more version control and development workflow content, see the developer tools category, such as Git workflow for website development and Git deployment workflow; for teams migrating from SVN to Git, see upgrading SVN to 1.8 on CentOS.

Reference: SVN's official documentation on configuration files is the "Runtime Configuration Area" chapter at https://svnbook.red-bean.com/en/1.8/svn.advanced.confarea.html.
Original post: https://www.cnblogs.com/cqzhuomi/articles/17284339.html (cnblogs.com CQZHUOMI, repost)