Bug 328873 - Need enhanced pattern support for ignoring resources
Summary: Need enhanced pattern support for ignoring resources
Status: ASSIGNED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Team (show other bugs)
Version: 3.5.2   Edit
Hardware: PC Linux
: P3 normal with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Platform Team Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-27 14:16 EDT by Rafal CLA
Modified: 2019-09-06 16:18 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rafal CLA 2010-10-27 14:16:47 EDT
Build Identifier: 3.5.2

Summary Description of Problem / Request:

CCRC should provide a more detailed pattern syntax for ignoring directories.  Full regular expression support or support for special variables like $project_dir would be great.


Detailed Description of Problem / Request:

Users need the ability to carefully control which view private files and directories are ignored by CCRC.  This is done using the Eclipse Team -> Ignored Resources preference.  Ignored resources do not cause the automatic prompt for adding to the repository, and they are not shown in the output from ClearCase Search.

Currently CCRC supports a basic wildcard pattern syntax.  You can specify a file extension to ignore, such as "*.exe".  You can also specify a pattern that includes directories, such as "*/obj/*".

My team needs to ignore entire directory trees containing generated files, but the pattern needs to be more specific.  The pattern "*/obj/*" will ignore files in any of the following directories:

* <project>/obj/...
* <project>/src/models/classes_and_objects/obj/*
* <project>/src/files_from_vendor_abc/sdk/obj/...

As you can see, an attempt to ignore generated files in the project's top level "obj" directory also ignores important repository files in the source tree.

True regular expression support could solve this problem.  So could support for special variables like $project_dir.  For example, an ignore pattern "/${project_dir}/obj/*" would provide exactly what we need.

We are currently adding project-specific ignore patterns to work around this problem.  So when project_abc is created, we create several ignore patterns like "/project_abc/obj/*" and "/project_abc/images/*".  However this is error prone and clutters the Ignored Resources preference.  We have also had cases where  ignore patterns seemed to be discarded by Eclipse when the user had a large number of projects.  It may be that there is a max length limitation to Eclipse preferences that causes this work-around to fail. 

Reproducible: Always

Steps to Reproduce:
1.  Eclipse Team
2.  Ignored Resources preference
3.
Comment 1 Rafal CLA 2010-10-27 14:18:54 EDT
Just FYI, this is the link to reference for Team Ignored Resources.

http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.user/reference/ref-20.htm
Comment 2 Tomasz Zarna CLA 2010-11-04 11:02:10 EDT
Sounds reasonable to me, looking forward to see a patch proposal. If you don't know where to start, I'm eager to help. Just ping me.
Comment 3 Tomasz Zarna CLA 2010-11-18 09:07:31 EST
Rafal, I just realized that you might be dealing with the same problem as described on bug 279111. Please take a look at the last comments and attached unit tests to see how to work with regex patterns in filters.
Comment 4 Rafal CLA 2010-11-18 18:05:42 EST
Tomek, Thanks for pointing out, but I think that bug is where they implemented the general wildcarding that was delivered in CCRC 7.1.1.1. It does not refer to having a $project variable or something similar to meet our requirement.  Thanks.
Rafal Konik
Comment 5 Eclipse Webmaster CLA 2019-09-06 16:18:37 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.