In any given working copy there is a good chance that alongside all those versioned files and directories are other files and directories which are neither versioned nor intended to be. Text editors litter directories with backup files. Code compilation processes generate intermediate—or even final—files which you typically wouldn't bother to version. And users themselves drop various other files and directories wherever they see fit, often in version control working copies.
It's ludicrous to expect Subversion working copies to be somehow impervious to this kind of clutter and impurity. In fact, Subversion counts it as a feature that its working copies are just typical directories, just like unversioned trees. But these not-to-be-versioned files and directories can cause some annoyance for Subversion users. For example, because the svn add and svn import commands act recursively by default, and don't know which files in a given tree you do and don't wish to version, it's easy to accidentally add stuff to version control that you didn't mean to. And because svn status reports, by default, every item of interest in a working copy—including unversioned files and directories—its output can get quite noisy where many of these things exist.
So Subversion provides two ways for telling it which files you would prefer that it simply disregard. One of the ways involves the use of Subversion's runtime configuration system (see the section called “Runtime Configuration Area”), and therefore applies to all the Subversion operations which make use of that runtime configuration, generally those performed on a particular computer, or by a particular user of a computer. The other way makes use of Subversion's directory property support, is more tightly bound to the versioned tree itself, and therefore affects everyone who has a working copy of that tree. Both of the mechanisms use file patterns.
The Subversion runtime configuration system provides an
global-ignores, whose value is a
whitespace-delimited collection of file patterns (or globs).
These patterns are applied to files which are candidates for
addition to version control, as well as to unversioned files
which the svn status command notices. If the
filenames match one of the patterns, Subversion will basically
act as if the file didn't exist at all. This is really useful
for file patterns which are nearly universally of the variety
that you don't want to version, such as editor backup files like
When found on a versioned directory, the
svn:ignore property is expected to contain a
list of newline-delimited file patterns which Subversion should
use to determine ignorable objects in that same directory.
These patterns do not override those found in the
global-ignores runtime configuration option,
but are instead appended to that list. And it's worth noting
again that, unlike the
the patterns found in the
property apply only to the directory on which that property is
set, and not to any of its subdirectories. The
svn:ignore property is a good way to tell
Subversion to ignore files that are likely to be present in
every user's working copy of that directory, such as compiler
output or—to use an example more appropriate to this
book—the HTML, PDF, or PostScript files generated as the
result of a conversion of some source DocBook XML files to a
more legible output format.
Subversion's support for ignorable file patterns extends only to the one-time process of adding unversioned files and directories to version control. Once an object is under Subversion's control, the ignore pattern mechanisms no longer apply to it. In other words, don't expect Subversion to avoid committing changes you've made to a versioned file simply because that file's name matches an ignore pattern—Subversion always notices all of its versioned objects.
The global list of ignore patterns tends to be more a
matter of personal taste, and tied more closely to a user's
particular tool chain than to the details of any particular
working copy's needs. So, the rest of this section will focus
svn:ignore property and its
Say you have the following output from svn status:
$ svn status calc M calc/button.c ? calc/calculator ? calc/data.c ? calc/debug_log ? calc/debug_log.1 ? calc/debug_log.2.gz ? calc/debug_log.3.gz
In this example, you have made some property modifications
button.c, but in your working copy you
also have some unversioned files: the latest
calculator program that you've compiled
from your source code, a source file named
data.c, and a set of debugging output log
files. Now, you know that your build system always results in
calculator program being generated.
And you know that your test suite always leaves those debugging
log files lying around. These facts are true for all working
copies of this project, not just your own. And you know that
you aren't interested in seeing those things every time you run
svn status, and pretty sure that nobody else
is interested in them either. So you use svn propedit
svn:ignore calc to add some ignore patterns to the
calc directory. For example, you might add
this as the new value of the
After you've added this property, you will now have a local
property modification on the
directory. But notice what else is different about your
svn status output:
$ svn status M calc M calc/button.c ? calc/data.c
Now, all that cruft is missing from the output! Of course,
calculator compiled program and all
those logfiles are still in your working copy. Subversion is
simply not reminding you that they are present and unversioned.
And now with all the uninteresting noise removed from the
display, you are left with more interesting items—such as
that source code file
data.c that you
probably forgot to add to version control.
Of course, this less-verbose report of your working copy
status isn't the only one available. If you actually want to
see the ignored files as part of the status report, you can pass
--no-ignore option to Subversion:
$ svn status --no-ignore M calc M calc/button.c I calc/calculator ? calc/data.c I calc/debug_log I calc/debug_log.1 I calc/debug_log.2.gz I calc/debug_log.3.gz
As mentioned earlier, the list of file patterns to ignore is
also used by svn add and svn
import. Both of these operations involve asking
Subversion to begin managing some set of files and directories.
Rather than force the user to pick and choose which files in a
tree she wishes to start versioning, Subversion uses the ignore
patterns—both the global and the per-directory
lists—to determine which files should not be swept into
the version control system as part of a larger recursive
addition or import operation. And here again, you can use the
--no-ignore option to tell Subversion ignore
its ignores list and operate on all the files and directories
 Isn't that the whole point of a build system?