Ignore stylecop whole file

Ignoring unversioned objects

In any given working copy, there is a likelihood that in addition to all of the versioned files and directories, there are other files and directories that are neither versioned nor intended to be versioned. Text editors throw away working copies with backup copies, software compilers create intermediate or even target files that you would normally never version. Users themselves also put various other files and directories where it suits them, often in version-controlled working copies.

It's silly to assume that working copies of Subversion are somehow immune to this kind of clutter and pollution. In fact, Subversion sees it as a feature suggest that its working copies are just ordinary directories, just like unversioned file trees. However, these unversioned files and directories can sometimes cause trouble for Subversion users. For example, the commands svn add and svn import working recursively by default and not knowing which of the files in the tree you want to version and which you don't, it is easy for something to be inadvertently brought under version control. And because svn status shows every interesting object of a working copy by default - including unversioned files and directories - its output can be quite noisy, especially where many of these things are.

So Subversion gives you two options for telling it which files you would rather ignore. One option uses the runtime configuration system (see “Runtime Configuration Area”) and therefore affects all Subversion functions that use these runtime settings - generally those that are executed on a specific computer or by a specific user . The other option uses Subversion's support for directory properties and is more closely tied to the versioned tree, affecting anyone with a working copy of that tree. Use both of these options File pattern (Strings of normal characters and those with special meaning that are compared to file names) to decide which files can be ignored.

Subversion's run-time configuration system provides an option whose value is a collection of file patterns separated by white space. The Subversion client compares these patterns both with the file names of the candidates to be brought under version control and with the names of the unversioned files that are svn status recognizes. Basically, if the name of any file matches a pattern, Subversion behaves as if the file doesn't exist. This is really useful for the sorts of files you almost never want to version, like editor backups like the and files from Emacs.

File pattern in Subversion

File pattern (also Globs or Shell wildcard called) are strings of characters that are to be compared with file names, typically for the quick selection of a subset of files from a larger collection without having to name each individual file. The patterns contain two kinds of characters: normal characters, which are compared with possible hits as indicated, and special wildcard characters, which are interpreted in a different way for the comparison.

There are different types of file pattern rules, but Subversion uses the variant common on Unix systems as it is implemented there in the system function. It supports the following wildcards, which are described here for the sake of simplicity:

Matches any single character

Matches any string, including the empty one

Beginning of a character class definition which is terminated by; matches a subset of characters

You can observe the same behavior when comparing file patterns when prompted in a Unix shell. Here are some examples of patterns for different things:

$ ls ### the source text files of the book 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 chapters of the book 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 chapters whose names end in zero ch00-preface.xml ch10-world-peace-thru-svn.x ml $ ls ch0 [3578] - * ### the chapters 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 complicated than described here, but keeping it at this basic level is sufficient for the majority of Subversion users.

If the property occurs on a versioned directory, the value is expected to contain a list of file patterns (separated by newlines) that Subversion should use to determine ignorable objects in that directory. These file patterns do not override those found in the runtime configuration option, but are appended to their list. At this point it is worth pointing out again that, unlike the option, the pattern of the property only applies to the directory in which the property is set, not even to any subdirectory. With the property, Subversion can be easily instructed to ignore files that are likely to appear in this directory of each user's working copy, such as compiler output or - to give an example more appropriate to this book - the HTML, PDF or PostScript files that are created as a result of converting the DocBook XML source text files into a more readable format.


Subversion's support for ignorable file patterns only extends to the one-time act of putting unversioned files and directories under version control. Once an object is under Subversion's control, the ignore patterns no longer affect the object. In other words, don't expect Subversion to prevent changes you've made to a versioned file from being broadcast just because that file's name matches an ignore pattern - Subversion will respect it always all of its versioned objects.

The global list of ignore patterns tends to be more a matter of personal preference and depends more on a user's tool chain than on the needs of a particular working copy in detail. Therefore, the remainder of this section focuses on the property and its uses.

For example, suppose you have the following output of 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 made some changes to properties of, but you also have some unversioned files in your working copy: the latest program you compiled from your source code, a source code file named, and a bunch of debugging log files. They know that the build system always creates a program.[19] And you know that the test environment always leaves these log files behind. This applies to all working copies of this project, not just your own. And you know that you have no interest in doing these things every time you call svn status to see, you're pretty sure others don't care, either. So call to add a couple of ignore patterns to the directory.

$ svn propget svn: ignore calc calculator debug_log * $

After adding this property, you now have a property change for the directory. However, note what else is different about yours svn status-Output is:

$ svn status M calc M calc / button.c? calc / data.c

Now the superfluous garbage is missing in the output! The compiled program and all of these log files are still in your working copy; Subversion just doesn't keep reminding you that they're there and unversioned. And now that all the noise is gone, the more compelling items remain - like the source code file that you probably forgot to put under version control.

Of course, this more compact report of the health of your working copy is not the only one available. If you really want to see the ignored files in the report, you can give Subversion the option:

$ 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 used. Either of these commands will cause Subversion to begin managing a bunch of files and directories. Rather than forcing the user to select files from a tree of files to be placed under version control, Subversion uses the ignore patterns - both global and directory-linked lists - to determine which files should not be included in a major recursive addition or operation Import action should be brought into the version control system. Again, you can use the option to tell Subversion to ignore the ignore lists, and work on any files and directories that exist.


Even if is set, you might run into problems if you use shell wildcards in a command. Shell wildcards are expanded to an explicit list of target objects before Subversion processes them, so calling to works just like calling. In the case of the command svn add does this have an effect similar to the option to pass. Instead of using wildcards, you should use them to reserve a large number of unversioned items for version control. The explicit goal ensures that the current directory is not overlooked because it has been under version control for a long time, and the option causes Subversion to work its way through that directory and add unversioned files, taking property and run-time configuration variables into account become. Make sure you have the command svn add also give the option if you do not want a fully recursive walk through to add.