Choosing Between svn:ignore and global‑ignores in Subversion

Decision and constraints

When working with Subversion you often need to keep build artefacts, log files, or editor temporary files out of the repository. The goal is to have a reliable ignore mechanism that works for all developers, regardless of their operating system, while keeping administrative effort low.

Options comparison

Option	Scope	Persistence	Admin overhead
svn:ignore property	Per‑directory (inheritable to sub‑directories)	Stored in the repository as a versioned property	Requires svn propedit and a commit to change
global‑ignores (runtime config)	Per‑user working copy	Stored in ~/.subversion/config (or the Windows equivalent)	No repository change; each user must set it locally

Trade‑offs

• svn:ignore – The ignore list is version‑controlled, so every checkout automatically receives the same rules. This eliminates mismatches between team members. The downside is that the repository accumulates metadata and any change to the ignore list requires a new commit.
• global‑ignores – Setting ignores in the client configuration is immediate and does not affect the repository history. It is useful for personal‑specific patterns (e.g., editor backup files). However, each developer must replicate the setting, and if the configuration diverges, some users may see unwanted files in svn status while others do not.

Implementation example – using svn:ignore

1. Ensure you have a clean working copy: svn update.
2. Edit the ignore property for the directory where you want to ignore files (here the repository root):

   svn propedit svn:ignore .

   This opens your configured editor.
3. Add one pattern per line, for example:

   build*
   *.log
   *.tmp
   

   Save and close the editor.
4. Commit the property change:

   svn commit -m 'Add ignore rules for build outputs and logs'

5. Verify that the property is stored:

svn propget svn:ignore -R .

The output should list the patterns you added, one per line.

1. Create a file that matches a pattern to test the ignore:

   mkdir -p build
    touch build/tmp.o
    touch debug.log
   

Run svn status from the working copy root. Files matching the ignore patterns should appear with a leading '?' (indicating they are not under version control) and should not be scheduled for addition.

Verification steps

• Property persistence: svn propget svn:ignore -R . returns the exact lines you entered.
• Ignore effectiveness: After creating a test file matching a pattern, svn status shows the file as '?' and does not list it under 'A' (added).
• Ensure ignored files are not accidentally added: Running svn add . should skip the ignored files and only schedule non‑ignored items.

Limitations and practical checks

• Files already under version control are not affected by either ignore mechanism. To stop tracking such a file, first run svn delete --keep-local <file> and commit the deletion, then rely on the ignore rule to prevent it from being re‑added.
• Global‑ignores only affect the machine where they are configured. To verify consistency across a team, each member can run svn propget svn:ignore -R . and compare the output; any divergence indicates a mismatch that must be resolved by aligning the repository property or updating local configs.
• If you need a pattern that varies per developer (e.g., personal editor backup files), combine both approaches: keep the shared patterns in svn:ignore and add personal patterns to ~/.subversion/config under the [global-ignores] section.