Community
Participate
Working Groups
For instance if I want to ignore /toolname/product/en_US/index [this is a directory] then I should be able to use the above as the pattern to ignore it.
Can't you use the .cvsignore file instead of the global ignore list? Is there a reason why .cvsignore isn't what you need in this case?
Yeah there is a reason. Ignored resources are based on pattern matching where as .cvsignore is based on resources that belong to that hierarchy. So if I would like to ignore all Help/index directories in my project, let's say I have 20 tools each with a Help/index directory. I would have to go into 20 .cvsignore files of that tools Help directory instead of just adding "Help/index" as the pattern in the ignored resources. There are cases where only one developer of a team will have a set of resources. This set of resources does not need to be checked into cvs so that developer would like them to be ignored, however, these ignored resources don't apply to other developers so it doesn't make sense to add them to the .cvsignore file which the other developers are using. Hope that makes sense, MG
What happens when you add 'index' to the global ignore list?
Then it ignores all directories named index and not just directories named index whos parent is Help.
Eclipse provides a mechnism to do what you asked. Resources that are the output of a build process can be marked as "derived" (see IResource#setDerived (boolean)). JDT uses this mechanism to indicate to repository providers tha *.class files should be ignored. The build tool you are using to generate these index files could do the same thing (assuming it is an Eclipse plugin).
I use lucene - jakarata search engine - a non-eclipse plugin to generate the index files. Is my use case for this not clear? Basically I like to use the globally ignored resources for two cases: The first is when I want to globally ignore a certain set of files. The second is when I have files in my source tree which are specific to me and not the project I don't like to clutter everyone else's .cvsignore file with exclusions specific to my environment so I put them in the globally ignored resouces setting. I think allowing the globally ignored resources to be more flexible and take a directory pattern would be valuable because it would allow one to ignore files in certain cases. For instance I could ignore all text files that appear in all test directories. No matter where in my source tree those test directories were located and this is without having to go into each test directory and use the .cvsignore file.
No, we understand your request but required more information to decide how to handle it at this time. This what I understand is your scenario: 1) You have a shared project 2) You use an external build tool so IResources cannot be marked as "derived" 3) The build tool generates build output that does not have a unique file extension or file name (making the use of a file pattern based global ignore facility unhelpful) 4) No one else who works on the project uses this tool so using a repository specific ignore mechanism (i.e. .cvsignore) is not acceptable. Here is my assesment of this: 1) This is an uncommon workflow. I also find it odd that a build tool produces unqualified (i.e. no extension) file names with the name index. 2) It is not just a simple change given that the Team API states that the ignore list is file patterns not paths. In essence, this would be a breaking API change that would require PMC approval.
Makes sense. Thanks for looking into it !
I think also this requirement make sense. But there is an other solution like asked in the bug 30440 : offer an ANT script that allows to set the derived flag. This solution would work to solve your specific problem. But more generally, the things asked here should also be usefull if : The files that you don't want to export in a repository are not generated from an ant script (expl: temporary output files of some test execution), and the team provider doesn't provide a specific way to ignore some files.
*** Bug 41637 has been marked as a duplicate of this bug. ***
*** Bug 46312 has been marked as a duplicate of this bug. ***
We need the ignored resources fixed to work with an internal Version Control system. This internal version control system only uses ignored resources. And its not just a multi directory pattern it seems to be any directory....
You go to Team->Ignore Resources preference. And then put add *3rdpartylibs* And as far as I can see it doesn't seem to recognize it at all..
Seen the duplicates, I presume OS can be changed to 'All' and version can be decreased to 2.1.1 (I suppose the lowest wins). I suppose this bug includes the fact that Eclipse can't ignore its own 'bin' directory.
*** Bug 71802 has been marked as a duplicate of this bug. ***
There is currently no plan to address this item.
*** Bug 105971 has been marked as a duplicate of this bug. ***
Moving back to OPEN state
*** Bug 194182 has been marked as a duplicate of this bug. ***
Created attachment 72454 [details] patch proposal I believe this is the simplest approach. This patch allows you to use '/' in your filters. All filters that contains '/' are checked for resource relative (to the project) path Previous behavior of normal filters is kept.
The main problem I have with the patch is the format of the folder path. I had to look at the code to determine what the pattern was. The culprit was the addition of a leading slash to the resource project relative path. Why did you do this? I wonder if it wouldn't be better to use the full path and have the users add a * to the start for paths (e.g. */folder1/file)?
(In reply to comment #22) > The main problem I have with the patch is the format of the folder path. I had > to look at the code to determine what the pattern was. The culprit was the > addition of a leading slash to the resource project relative path. Why did you > do this? I used leading / to show that this paths begins in the "project root". This is the only way to differeciate between foo.txt and bar/foo.txt if we use /foo.* pattern only first file will be ignored. With this solution you can still use *somepath/somefolder/... to specify fragment paths and /paths/from/project to specify full project relative paths
The sentence "I used leading / to show that this paths begins in the "project root"" makes no sense to me. To me, a leading / means that the path is absolute (i.e. that is the general meaning of a leading slash). As an illustration, if I have a file "/project1/folder1/file1", it is not intuitive that the ignore pattern should be "/folder1/file1". However, I would expect the following patterns to work: file1 */file1 */folder1/file1 /project1/folder1/file1
Created attachment 72704 [details] change to suggested behavior I agree with your justification. here is changed patch. now it works according to your expectation.
*** Bug 150578 has been marked as a duplicate of this bug. ***
Thanks for the patch. Patch released to HEAD.
Verified in build I20070808-1800
Michael, is that possible to put that patch into 3.3 maintenance stream?
This is an enhancement, not a fix for a 3.3 issue.
