Excluding Eclipse Project Resources from Version Control

If you have installed the Team Foundation Server plug-in for Eclipse on your local computer, Eclipse will automatically detect new, changed, or deleted resources in projects, and the Team Foundation Server plug-in for Eclipse adds those resources to its list of pending changes. Resources that are derived from another resource, such as output files from the build process, are not usually added to the list of pending changes. However, some build configurations, such as those that perform external build steps, might create resources that Eclipse does not know are derived. To prevent these resources from becoming pending additions to version control, you can specify two sets of filters to determine which resources should be excluded from version control:

Ignored Resources

In Eclipse, you can specify resources to ignore by using the Ignored Resources page under the Team preference category. This page contains a list of wildcard characters that apply to project resources, and any matching resources are not added to the list of pending changes. The Team Foundation Server plug-in for Eclipse tests against this list first so that you can use it instead of the .tpignore file in many circumstances. However, these preferences cannot be easily shared with other team members. Each team member must configure Ignored Preferences for each Eclipse workspace on their local computer. In addition, these preferences match only the last segment of a resource path: the file or directory name at the end. Therefore, you might prefer to use the .tpignore file.

To modify the Ignored Resources

  1. On the Window menu, click Preferences.

    The Preferences dialog box appears.

  2. In the list of categories, expand the Team node, and click Ignored Resources.

  3. Perform one or more of the following tasks:

    • To ignore a pattern that appears in the Ignore Patterns list, select the check box that corresponds to the pattern.

    • To stop ignoring a pattern that appears in the Ignore Patterns list, clear the check box that corresponds to the pattern.

    • To add a pattern to the Ignore Patterns list, click Add Pattern, and then specify the pattern that you want to add.

      By default, the check boxes for all new patterns are selected.

  4. Click OK to save your changes.

.tpignore File

You can specify a file named .tpignore at the root directory of an Eclipse project. The Team Foundation Server plug-in for Eclipse checks this file each time that it examines an Eclipse resource. If the new resource matches any pattern in the file, the resource is not added to the list of pending changes. If the resource does not match any of those patterns, it is added to the list of pending changes.

You do not need to manually modify the .tpignore file. You can ignore files or folders by performing the following steps:

  1. In Package Explorer, right-click the file or folder that you want to exclude, point to Team, and then click Ignore.

    An Ignored label appears next to the file name.

    The plug-in automatically adds the patterns of the ignored file to the .tpignore file. For more information about the patterns in the .tpignore file, see .tpignore File Format.

You can add the ignored resources back to the list of pending changes by performing the following steps:

  1. In Package Explorer, right-click the file or folder that you want to include, point to Team, and then click Unignore.

    The Ignored label disappears.

    The plug-in automatically removes the matching regular expression from the .tpignore file. If the regular expression matches more than one file, a Choose Patterns To Remove dialog box appears.

  2. In the Choose Patterns To Remove dialog box, specify the patterns that you want to remove, and then click Remove Patterns.

You do not need to restart Eclipse after you modify the .tpignore file. Your changes take effect when the next resource event occurs. The plug-in also automatically loads changes that were made to this file if a new version of this file is retrieved from version control.

By default, files that begin with a period do not appear in Package Explorer, but you can modify your Package Explorer filters to display files that start with a period. After you create a .tpignore file, you can add it to version control so that other developers who are using the plug-in can use your patterns. You do not have to add the .tpignore file to version control to use it on your local computer. For more information about the format of the .tpignore file, see .tpignore File Format.

To cause the Team Foundation Server plug-in for Eclipse to start automatically adding discovered resources to the list of pending changes, remove or make into a comment the line or lines in the .tpignore file that match the resources that you want to add.

Matching Behavior

The patterns in the .tpignore file are Java regular expressions. Matches are performed in a case-insensitive way on operating systems where the file system is case-insensitive and in a case-sensitive way on operating systems where the file system is case-sensitive.

When the plug-in tests an Eclipse resource path for a directory against a regular expression in the .tpignore file, the plug-in ensures that the path always ends in a slash (/) before the test is performed. This enables your regular expressions to be simpler when you want to match a directory. Paths to file resources never end in a slash. All resource paths that start with a slash, and it is important to remember this when you write your patterns.

.tpignore File Format

The .tpignore file is a text file. Each line is either a comment line or a pattern line. Each pattern line contains a single Java-style regular expression. The path of a newly discovered Eclipse resource that matches any pattern in the .tpignore file is not added to the list of pending changes. Leading and trailing whitespace on each line is ignored when expressions are read from the .tpignore file.

Backus-Naur Form (BNF)

    <.tpignore>             ::= { <line> }
    <line>                  ::= <comment-line> | <pattern-line> <EOL>
    <comment-line>          ::= "#" <ignored-text>
    <pattern-line>          ::= <java-regular-expression>

Example

You might use the following .tpignore file:

    # Lines that begin with #, like this one, are ignored.
    .*/core
    .*\.class
    .*/[^/]+\.class
    /some/path/README
    /output/.*
    /bin/

Each line is described as follows:

  1. The first line shows a comment that will be ignored. A .tpignore file may contain zero or more comment lines.

  2. The second line shows a regular expression that will match any Eclipse resource path for a file that ends with the characters “/core”, including /core, /bin/core, and /some/long/path/core. The “.*” is regular expression syntax that means "match zero or more occurrences of any character." The rest of the line specifies literal characters to match. Resource /bin/core/main.c would not match because there are additional characters in the resource path after the literal part of the expression /core. It will not match directories because all directories end with a slash.

  3. The third line shows a regular expression that will match any Eclipse resource path for a file that ends with the characters “.class”. The period in the extension must be escaped because the period has a special meaning in Java's regular expression syntax (it matches any character). This expression would match files named /Program.class or /some/long/path/Program.class. It will not match directories because all directories end with a slash.

  4. The fourth line shows a regular expression that will match any Eclipse resource path for a file that ends with the characters “.class” and that has at least one character before the period in the last segment of the path. As in the third line, the period in the extension must be escaped. The expression syntax [^/] means "match all characters in this group, and this group contains all characters except for slash." This lets the expression match /some/long/path/File.class but not /some/long/path/.class. It will not match directories because all directories end with a slash.

  5. The fifth line shows a regular expression that uses no special syntax but is still evaluated as a regular expression. It simply matches any file named exactly "/some/path/README". It would not match the directory resource "/some/path/README/", because directory resource paths always end in a slash.

  6. The sixth line shows a regular expression that matches the directory resource "/output/" and any of its children, whether they are files or directories. It will not match a file "/output" because the pattern requires a trailing slash, which file paths do not have.

  7. The seventh line shows a regular expression that matches only the directory resource "/bin/" and not its children. It does not match a file at "/bin" because it specifies a trailing slash that is present only in directory paths.

See Also

Tasks

Check in Pending Changes (Team Explorer Everywhere)

Concepts

Applying Unix Filesystem Attributes to Files under Version Control

Other Resources

Placing Files under Version Control (Team Explorer Everywhere)