Community
Participate
Working Groups
Build ID: 3.5RC2 I20090522-1710 Steps To Reproduce: 1. Use team provider (in my case ClearCase Remote Client) 2. Add ignore patterns: src/fooand src/com/hal/foo 3. create project with src folder, and com/hal package 4. Add folder footo src, resource isn't ignored and is prompted to add to source 5. Add folder foo to src/com/hal and folder isn't ignored. 6. Wildcards are not honored (eg. src/foo/* will continue to throw resource change events for things added to folder foo) 7. Folder foamy is not prompted to add to source when the ignore pattern is just "foo" (no wild cards, no path info) regardless of where it's placed (as expected). More information: It would be most advantageous if ignored resources patterns would (in the circumstances of a folder pattern such as src/foo/*) ignore the folder and subsequent additions to the folder for adding to source control. The closed bug 39239, seems to imply this functionality was added in eclipse 3.4, however the behavior seems different from my interpretation of the description/discussion in that particular defect. In particular, Mike Valenta's note, dated 2007-06-28: "...However, I would expect the following patterns to work: file1 */file1 */folder1/file1 /project1/folder1/file1" implies to me that such patterns should function, yet they do not.
In addition... I would also expect the pattern: foo/bar/* to ignore all added to folder bar and it also does not.
Please go to: Workbench User Guide > Tasks > Working in the team environment with CVS > Synchronizing with the repository > Version control life cycle: adding and ignoring resources In particular this snippet: It is important to note that the path leading up to the resource name is not included in the matching. For example, for the file "/path/to/file.txt", only the string "file.txt" is matched against the patterns. This facility is not intended for specifying fully-qualified path names but for specifying globally applicable patterns.
But it would be *exceedingly useful* to be able to use the ignored resource patterns to block off a folder and it's contents from src control. So the thing is, when I put in a pattern such as src/foo or src/com/hal/foo and then I add folder foo to src, or add foo to hal, I still get prompted to add foo to source control. I would have thought that the ign. res. mechanism would prevent that.
Does ClearCase Remote Client provides a facility similar to .cvsignore?
ccrc does not provide a mechanism similar to .cvsignore.
I see two solutions for the problem. One is to enhance global ignore patterns facility so you can specify a resource with its children. This way other Eclipse team providers that don't have a feature similar to .cvsignore would benefit. The second resolution would be to provide such a feature in ClearCase. This would give the requested functionality for all Clear Case clients, not only the Eclipse one. John, what do you think about it?
Changing severity to state clearly that we're talking about an enhancement request.
Pawel, We'd really like to have the enhanced global pattern capability. My understanding is that our group will have a representative at the IES 3.6 requirements meeting for discussion of the matter.
(In reply to comment #0) > "...However, I would expect the following > patterns to work: > > file1 > */file1 > */folder1/file1 > /project1/folder1/file1" > > implies to me that such patterns should function, yet they do not. (In reply to comment #1) > I would also expect the pattern: foo/bar/* to ignore all added to folder bar and > it also does not. This is because bug 39239 adds support for regular expressions so "*/folder1/file1" or "foo/bar/*" will not work as expected. "*" is treated as a greedy quantifier there not as a wildcard character as you would expect. In order to make it work you should use something like "/foo/bar/.*". Have you guys tried that?
The only limitation that I see looking at the patch from bug 39239 is the fact that a filter needs to contain '/' in order to be treated as a regular expression. We should get rid of it in the first place.
I stumbled across the information I needed to provide this function for our plugins. The way this will work for us is a pattern of */aaaa/* will ignore folder aaaa and it's descendants or a pattern such as */aaaa*/* will ignore any folder that starts with aaaa and it's descendants.
Setting target milestone to 3.6M5 as in http://www.eclipse.org/eclipse/platform-team/team3.6/plan.php
Please ignore comments 9 and 10, bug 39239 adds something called "path pattern" which enables matching given pattern with resource's full path (if the pattern contains at least one '/' character). It has nothing to do with regular expressions, my mistake. I looked at your scenario (comment 11), wrote some unit tests (patch is coming) and came to a conclusion that we have three options here: 1) Instead of using single pattern of '*/aaaa/*' to match folder 'aaaa' and all files and subfolders you will need to use two patterns: '*/aaaa' (to match the folder), '*/aaaa/*' (to match it's descendants). The context help for the preference page says "'/*/a/*' matches all files and sub-folders in '/x/a/' and also in '/x/y/z/a/'", it means that '/x/a/' folder is not matched. I'm afraid this is a contract we cannot break. 2) Add support for regular expressions. If a full path of a resource matches against a regex the resource will be ignored. 3) We could also consider breaking the contract from 1) and add a note to Migration Guide about it. But I'd rather not do that.
Created attachment 151301 [details] Tests v01 Please, take a look at org.eclipse.team.tests.ccvs.core.cvsresources.EclipseSynchronizerTest.testBug279111_comment11(), this is the situation described in comment 13, bullet 1). All tests pass.
Created attachment 151302 [details] mylyn/context/zip
Created attachment 151303 [details] Minor changes to related classes.
Created attachment 152029 [details] Tests v02 Tests extended for patterns "/*/aaaa" and "/*/aaaa*". They both cover a folder (or folders), subfolders and files at the same time. In other words, ignoring a folder affects all subfolders and files as well. This proves that with minor changes to your patterns ("*/aaaa/*" -> "/*/aaaa" and "/*/aaaa*/*" -> "/*/aaaa*") you can get the desired effect. If this is acceptable from your standpoint I would release the tests and mark the bug as resolved/worksforme as no changes are required in the real code to get this working. What do you think?
It looks very good.
Both patches applied to HEAD (tests and 'minor changes'), but since none of them modify the way ignoring resources works I'm marking the bug as WORKSFORME (see comment 17 for details). Tests and code update available in builds >=I20091117-0800 (building toward 3.6M4).
