This text is a work in progress—highly subject to change—and may not accurately describe any released version of the ApacheTM Subversion® software. Bookmarking or otherwise referring others to this page is probably not such a smart idea. Please visit http://www.svnbook.com/ for stable versions of this book.
In any given working copy, there is a good chance that alongside all those versioned files and directories are other files and directories that are neither versioned nor intended to be. Text editors litter directories with backup files. Software compilers generate intermediate—or even final—files that 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 several 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 that make use of that runtime configuration—generally those performed on a particular computer or by a particular user of a computer. Two other methods make use of Subversion's directory property support and are more tightly bound to the versioned tree itself, and therefore affects everyone who has a working copy of that tree. All of these mechanisms use file patterns (strings of literal and special wildcard characters used to match against filenames) to decide which files to ignore.
The Subversion runtime configuration system provides an
option, global-ignores, whose value is a
whitespace-delimited collection of file patterns. The
Subversion client checks these patterns against the names of the
files that are candidates for addition to version control, as
well as to unversioned files that the svn
status command notices. If any file's name matches
one of the patterns, Subversion will basically act as if the
file didn't exist at all. This is really useful for the kinds
of files that you almost never want to version, such as editor
backup files such as Emacs' *~ and
.*~ files.
File Patterns in Subversion
File patterns (also called globs or shell wildcard patterns) are strings of characters that are intended to be matched against filenames, typically for the purpose of quickly selecting some subset of similar files from a larger grouping without having to explicitly name each file. The patterns contain two types of characters: regular characters, which are compared explicitly against potential matches, and special wildcard characters, which are interpreted differently for matching purposes.
There are different types of file pattern syntaxes, but
Subversion uses the one most commonly found in Unix systems
implemented as the fnmatch system
function. It supports the following wildcards, described here
simply for your convenience:
?
Matches any single character
*
Matches any string of characters, including the empty string
[
Begins a character class definition terminated by
], used for matching a subset of
characters
You can see this same pattern matching behavior at a Unix shell prompt. The following are some examples of patterns being used for various things:
$ ls ### the book sources appa-quickstart.xml ch06-server-configuration.xml appb-svn-for-cvs-users.xml ch07-customizing-svn.xml appc-webdav.xml ch08-embedding-svn.xml book.xml ch09-reference.xml ch00-preface.xml ch10-world-peace-thru-svn.xml ch01-fundamental-concepts.xml copyright.xml ch02-basic-usage.xml foreword.xml ch03-advanced-topics.xml images/ ch04-branching-and-merging.xml index.xml ch05-repository-admin.xml styles.css $ ls ch* ### the book chapters ch00-preface.xml ch06-server-configuration.xml ch01-fundamental-concepts.xml ch07-customizing-svn.xml ch02-basic-usage.xml ch08-embedding-svn.xml ch03-advanced-topics.xml ch09-reference.xml ch04-branching-and-merging.xml ch10-world-peace-thru-svn.xml ch05-repository-admin.xml $ ls ch?0-* ### the book chapters whose numbers end in zero ch00-preface.xml ch10-world-peace-thru-svn.xml $ ls ch0[3578]-* ### the book chapters that Mike is responsible for ch03-advanced-topics.xml ch07-customizing-svn.xml ch05-repository-admin.xml ch08-embedding-svn.xml $
File pattern matching is a bit more complex than what we've described here, but this basic usage level tends to suit the majority of Subversion users.
When found on a versioned directory, the
svn:ignore property is expected to contain a
list of newline-delimited file patterns that 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 global-ignores option,
the patterns found in the svn:ignore
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 1.8 provides a more powerful version of the
svn:ignore property, the
svn:global-ignores property. Like the
svn:ignore property,
svn:global-ignores can only be set
on a directory and contains file patterns Subversion uses to
determine ignorable objects.[21] These ignore patterns are also
appended to any patterns defined in the
global-ignores runtime configuration option
together with any svn:ignore defined patterns.
Unlike svn:ignore however, the
svn:global-ignores property is inheritable
[22]
and applies to all paths under the directory on
which the property is set, not just the immediate children of the
directory.
| [Note] | Note |
|---|---|
|
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. |
Ignore Patterns for CVS Users
The Subversion svn:ignore property is
very similar in syntax and function to the CVS
.cvsignore file. In fact, if you are
migrating a CVS working copy to Subversion, you can directly
migrate the ignore patterns by using the
.cvsignore file as input to the
svn propset command:
$ svn propset svn:ignore -F .cvsignore . property 'svn:ignore' set on '.' $
There are, however, some differences in the ways that CVS
and Subversion handle ignore patterns. The two systems use
the ignore patterns at some different times, and there are
slight discrepancies in what the ignore patterns apply to.
Also, Subversion does not recognize the use of the
! pattern as a reset back to having no
ignore patterns at all.
The ignore patterns in the global-ignores
runtime configuration option tend to be more a
matter of personal taste[23] and ties 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
on the svn:ignore and
svn:global-ignores properies and their
uses.
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
to 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
logfiles. Now, you know that your build system always results
in the calculator program being
generated.[24] And you know that your test suite
always leaves those debugging logfiles 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 you are 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.
$ svn propget svn:ignore calc calculator debug_log* $
After you've added this property, you will now have a local
property modification on the calc
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! Your
calculator compiled program and all those
logfiles are still in your working copy; Subversion just isn't
constantly reminding you that they are present and unversioned.
And now with all the uninteresting noise removed from the
display, you are left with more intriguing 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
the --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 I calc/wip.1.diff
All of your previously hidden unversioned paths are once
again shown, but now with the 'I' Ignored
status. But wait, what about wip.1.diff?
The svn:ignore property on
calc doesn't include any pattern that
matches that filename, so why is it ignored?[25] The answer lies in the third method by which
Subversion can disregard unversioned paths, the inheritable
svn:global-ignores property. Using the
svn propget subcommand with the
--show-inherited-props option, you see that
the svn:global-ignores property is set on the
root of your working copy, and sure enough, it defines a
matching ignore pattern:
$ svn pg svn:global-ignores calc -v --show-inherited-props Inherited properties on 'calc', from '.': svn:global-ignores *.diff *.patch
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—the global, per-directory, and inherited
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 to disregard
its ignores list and operate on all the files and directories
present.
| [Tip] | Tip |
|---|---|
|
Even if |
[21] The ignore patterns
in the svn:global-ignores property may be
delimited with any whitespace (similar to the
global-ignores runtime configuration option),
not just newlines (as with the svn:ignore
property).
[22] Of course only a 1.8 or newer Subversion client
will recognize the inheritability and special meaning of the
svn:global-ignores property!
[23] Despite being a matter
of personal taste, if you don't explicitly set the
global-ignores runtime
configuration option—either to your preferred set of
patterns or to an empty string—Subversion uses a default
value. See the global-ignores entry in
the section called "General configuration"
[24] Isn't that the whole point of a build system?
[25]
Let's assume that you don't have a matching pattern anywhere
in your global-ignores runtime configuration.